HomeMy WebLinkAbout26 - Instructions - Enterprise Resource Planning Software & Implement addendum 2Request for Proposals (RFP)
Enterprise Resource Planning (ERP) Software
and Implementation Services
Addendum #2
April 7, 2026
ADDENDUM #2
This Addendum #2 is issued in response to questions and requests from vendors for the City of
Bozeman’s Request for Proposals (RFP) for Enterprise Resource Planning (ERP) Software and
Implementation Services. All responses reflect the City’s best information and understanding as
of the date of this Addendum. In some cases, responses describe current intentions,
preferences, or anticipated approaches that may be further refined during contract negotiation,
discovery, or implementation planning. Nothing in these responses should be construed as a
guarantee, commitment, or modification of the RFP beyond what is explicitly stated. All other
terms and conditions of the RFP remain unchanged unless expressly modified herein.
Respondents are responsible for reviewing and incorporating the information contained in this
Addendum into their proposals.
This Addendum has three (3) parts:
I. Responses to the written questions submitted by Respondents.
To improve clarity and readability, the City has organized the responses to submitted
questions into logical topic groupings (e.g., financials, budgeting, integrations,
implementation, change management). These groupings are provided solely as a
navigational aid and are not intended to redefine, limit, or otherwise characterize the
substance or importance of any individual question or response. Respondents are solely
responsible for reviewing all questions and all corresponding responses in their entirety,
regardless of how questions have been grouped, and for incorporating all relevant
information into their proposals.
II. Draft Future State Maps
The City has developed a set of future‑state concept maps through its internal working
groups as part of ERP readiness and requirements‑gathering efforts. These materials are
intended to be conceptual and illustrative, representing high‑level views of selected
business processes and desired outcomes. They do not represent detailed process designs,
end‑to‑end ERP workflows, or a complete catalog of City business processes.
The concept maps should not be interpreted as prescriptive, final, or exhaustive process
definitions, nor should they be construed as defining the full scope of the ERP
implementation. The City fully expects to work collaboratively with the selected vendor to
refine, adapt, and optimize business processes using industry best practices and the
capabilities of the proposed solution. Respondents remain responsible for proposing
processes and configurations that meet the City’s stated objectives, functional
requirements, and long‑term operational needs.
III. PowerPoint from Pre-Proposal Conference
Part I: Responses to Written Questions
1. Procurement Process, Submission Rules, and Administrative
Clarifications
1.1 Please send Preproposal Conference link and timing for Mar 24th.
City Response: The Preproposal Conference information was provided in
Addendum #1 to enable respondents to attend the meeting on March 24, 2026.
1.2 On page 12 it says “Answers to Submitted Questions to be Provided on April 7”.
Frequently, Published Answers to Questions create new Questions. As it appears the
City will not be responding to Questions until after he deadline to ask Questions
(March27). Will the City allow follow-up Questions to Answers which are Published after
the Deadline to ask Questions?
City Response: The City will respond to vendor questions through formal written
addenda by April 7. Responses issued by the City are final unless the City, at its sole
discretion, determines that additional clarification is required. The City is not
obligated to accept or respond to follow‑up questions submitted in response to an
addendum. Any additional clarification, if provided, will be issued via addendum
and shall not be construed as reopening the procurement.
1.3 We have several questions related to “Blind Review”: (a) On Page 32 it says: “For the Blind
Review submission, Respondents must redact all occurrences of Firm names, logos,
branding, or any other identifying information.” For purposes of this use of “Firm”, does
the City include only the Prime or all of the Firms in a Joint proposal, including: Software
vendor, System Integrator(s), and third-party software providers? (b) Respondents shall
not change the file name of any attachment but may append the file name to include the
Respondents name (e.g., FileName_CompanyABC).” How would the City like
FileName’s construction for the Blind review if we are not allowed to have the Firm Name
in the Blind Review?
City Response: For responses to the Blind Review submission, all Firms shall
redact identifying information. If Respondents need to distinguish between Firms in
the response, please use generic terms like Software Provider, Implementer,
Cashiering Provider, etc. Please see response 1.14 on the Module/System column
of the Functional Requirements attachment.
1.4 On page 36 it says: “c. Microsoft Excel attachments should be submitted as Excel files,
in addition to being included with the overall PDF Submittal Package.” Please clarify that
“in addition to being included with the overall PDF” that the City wishes the content of
the Excel file to be printed to PDF and inserted into the PDF response?
City Response: Respondents should include Excel versions of all attachments for
analysis. In addition, include a PDF copy of the Excel attachment, either integrated
into the full PDF submittal or as additional PDF attachments.
1.5 There are several places in the RFP that refer to a “Submittal Checklist”. We are unable
to find a list or checklist or a section entitled “Submittal Checklist”. Please either
confirm: (a) The tables labeled “Submission Package” on Pages 37 - 39 of the RFP are the
“Submittal Checklist”, or (b) Point us to where we may find the “Submittal Checklist”.
City Response: The Submittal Checklist refers to the tables on pages 37 & 38 of the
RFP that identify the information to be included in the submission. The checklist
themselves do not need to be submitted in the response.
1.6 Question on “Page Limits”. On page 36 in Footnote 1 it says: “1Attachments are excluded
from the page limit, but please note that any attachment that allows narrative response
should be answered as concisely as possible.” Further in the “Submission Package”
tables on pages 37 – 39 there is a column labeled “Page Limit1” Several of the sections in
these tables appear to only contain “Attachments” (e.g., “Respondent Team”) which are
excluded from Page Limits, however there are Page Limits in the Page Limit column.
Please clarify the City’s intent with Page limits as it relates to Attachments?
City Response: The City anticipates Respondents providing additional narrative
responses in addition to the attachments for the sections with page limits. For
example, in section IV.1.2 – Respondent Team, the City has requested a brief
summary of the Firm(s) responding to the RFP. This summary should be limited to 3
pages and is in addition to the attachments for that section (Attachments 1.1 – 1.6).
1.7 While it is premature for us to assume any down select decision before proposals are
due, we wanted to alert the City that the first two demo weeks (July 14/July 21) will
potentially prove challenging to us. May we respectfully request that some additional
flexibility be offered on scheduling down select dates, perhaps by adding additional
windows in early August?
City Response: The City will do its best to accommodate Respondents who are
down selected to demonstrations, however, it can only do so in a way that does not
jeopardize its general procurement goals and schedules.
1.8 The RFP says on page 36 “Respondents should fill out and include all attachments to this
RFP. Attachments shall not be altered. Alterations to attachments or a failure to follow
the guidelines below may result in the proposal being deemed non-responsive.” Further
on page 36 it says: “Microsoft Excel attachments should be submitted as Excel files, in
addition to being included with the overall PDF Submittal Package.”
Most of the Excel files are not setup to be printed and include the entire content (all rows
and columns of the tab) which is required to convert the Excel file to PDF. Assuming the
City wants the contents of the Excel files included in the PDF, can the City provide Excel
files which are print ready (i.e., all columns and rows of each tab can be printed on 8 1/2”
x 11” paper to allow insertion into the PDF Response)? Or allow the Respondent to
change the Page Setup in these files without characterizing that change as an “alteration”
of the file? Some of the Excel files have the Page Setup function protected (greyed out).
If the City wishes these Excel files to be included in the PDF can the City provide Excel
files which are print ready (i.e., all columns and rows of each tab can be printed on 8 1/2”
x 11” paper to allow conversion from Excel to PDF and insertion into the PDF Response)?
City Response: Respondents may make limited, non-substantive adjustments to
the provided Excel files solely as necessary to enable conversion to PDF (e.g.,
adjusting page setup or print settings). Respondents may not modify the content of
the files, including adding, removing, or altering rows, columns, formulas,
calculations, or data values, or otherwise changing the structure or format of the
worksheet content.
The City will conduct its evaluation using the submitted Excel files; the PDF versions
are provided only to preserve the integrity of the submitted information.
Accordingly, the PDF output does not need to be aesthetically formatted. One
acceptable approach is to select the populated cells and export to PDF using a
“Print Selection” option with columns scaled to fit on a page. Respondents may use
any PDF export method that meets these criteria without altering the underlying
Excel content.
1.9 Does the RFP have a unique reference number that must be included in the Title page?
City Response: No, the City does not currently number their RFPs.
1.10 Page Limits & Proposal Formatting: The RFP allocates only one page (Page 3) for the
entire “Respondent Team” section. However, this section must include multiple
mandatory attachments (V.1.2 Nondiscrimination & Equal Pay Affirmation, V.1.3
Respondent Statement, V.1.4 Software Background, V.1.5 Professional Services
Background, and V.1.6 Reference Form). Each completed Reference Form (V.1.6) in the
format required can easily consume a full page. Providing the standard three to five
references would therefore exceed the 3-page limit before any narrative is added. For
each sub contractor, the attachments would be required. Q 2. Will the City consider
increasing the page limit for the Respondent Team section or removing the page limit
entirely for this section to allow vendors to provide complete, properly formatted
reference forms and background information?
City Response: Attachments are excluded from the page limit count, but
Respondents are encouraged to answer as succinctly as possible. The page limit in
that section refers to the narrative request about the Respondent Team in section
IV.1.2.
1.11 If the 25 MB / single-file rule is firm, would the City prefer vendors to omit high-resolution
screenshots and reference forms from the main PDF and instead provide a secure link
(Box/SharePoint) to a separate appendix?
City Response: Per the RFP, file sizes greater than 25MB in size may be uploaded to
the City Clerks’ Office upon special arrangement with the City Clerk.
1.12 Is there flexibility in the demo schedule (July 14–30, 2026) for vendors with unavoidable
conflicts with other public-sector clients?
City Response: While the City will make reasonable efforts to accommodate minor
scheduling constraints, vendors should plan to be available during the designated
ERP demo timeframe outlined in the RFP. Due to the structured evaluation process
and coordination requirements, flexibility will be limited. Vendors are encouraged
to submit proposals that align with the established schedule.
Vendors may identify any significant scheduling conflicts in their proposal; if none
of the listed demo periods are feasible, vendors are still encouraged to submit and
provide detail on their availability. While adjustments are unlikely, the organization
will consider such constraints within the overall evaluation process.
1.13 Will the City provide the scripted demo test data set in advance, and what is the expected
volume of test records per module?
City Response: The City will not provide demonstration test data. Respondents are
expected to use their own representative test data to demonstrate the scenarios
outlined in the demonstration scripts and should ensure that the data volumes and
examples shown are sufficient to illustrate how the solution supports the City’s
business processes. Demonstration data need not reflect the City’s actual record
counts but must be sufficient to meaningfully demonstrate all requested scenarios
end to end.
1.14 Section V.2.1 instructs respondents to include the Module/System name in the
Functional Requirements attachment, which would identify the vendor. Should that field
be redacted in the Blind submission and only included in the Unblind package?
City Response: No, please include the Module/System name in the Blind
submission. That column will be hidden from the Evaluators during the Blind review.
Please be sure to redact any identifying information in the Comments column of the
Functional Requirements attachment.
1.15 Can you please provide clarification on the following RFP instructions? On Page 2 of the
RFP, it says that all proposals must be provided as a single, searchable PDF document
file. On Page 36 of the RFP, it states that Proposals must be submitted in two separate
submission packages... (Submission Package I – Unblind Review and Submission
Package II – Blind Review)
City Response: The City acknowledges that these instructions require clarification.
Proposals shall be submitted in two separate submission packages:
1. Submission Package I – Unblind Review, and
2. Submission Package II – Blind Review
Each submission package shall be provided as a single, searchable PDF document,
consistent with the submission instructions. The “single searchable PDF”
requirement applies within each submission package, not across both packages
combined.
In addition, any required Excel-based response templates or attachments shall be
submitted in both native Excel format and PDF format for each submission
package, as applicable. Respondents should ensure that the Blind Review package
does not include any identifying or proprietary information as outlined in the RFP.
1.16 As it appears the City is asking for Submissions to be e-mailed and you have an e-mail
size limit and we are submitting a PDF RFP Response and several Excel Files: Question -
Should Respondents submit multiple e-mails (one e-mail for each attachment)? If so,
should we label the e-mails, so the City knows that multiple e-mails make up the
submission (e.g., e-mail one of 10, etc.)?
City Response: The City would prefer to receive one email per submission. If your
files exceed the email limit, please coordinate with the Clerk’s office to upload your
files.
1.17 Does the Blind Review apply to both the RFP Response (PDF File) and all of the
Attachments? Assuming yes, please confirm you do not want Respondent or software
product names anywhere in the Blind Excel Attachments, not in the file names?
City Response: Please see responses to 1.14 and 1.15
2. Evaluation Approach & Relationship to Other Procurements
2.1 The RFP states separate procurements are planned for Utility Billing and Permitting. Will
the City evaluate vendors who respond to more than one RFP jointly or entirely
independently? Is there a preference for a single ecosystem vendor across all three?
City Response: Proposals submitted in response to each RFP will be evaluated
independently, using the evaluation criteria and committee defined for that specific
solicitation. Each evaluation committee will score proposals based solely on the
merits of the solution proposed for that functional area.
Separately, the City’s Steering Committee may facilitate discussions regarding
system interoperability, integration opportunities, and long‑term strategic
alignment across functional areas. These discussions will not alter evaluation
scores or rankings for any individual RFP. The City has no requirement or preference
for a single vendor across the ERP, Utility Billing, and Permitting and Licensing
systems.
Final award decisions will be based on each proposal’s ability to meet functional
and technical requirements, and may also consider overall operational value,
integration feasibility, and implementation risk, consistent with applicable
procurement rules.
2.2 If no Montana references exist, will their absence negatively affect scoring, or is the
request in Section V.1.6 aspirational only?
City Response: No. The absence of Montana‑specific references will not negatively
affect scoring, and the request in Section V.1.6 is not a mandatory requirement.
Respondents will be evaluated based on their overall qualifications, experience,
and ability to deliver a successful ERP implementation for the City.
That said, the City recognizes that experience implementing ERP solutions for
public‑sector organizations in Montana or comparable regulatory and operating
environments may provide helpful context—particularly for areas where
state‑specific requirements, reporting practices, or implementation considerations
may apply. Such experience may be cited by Respondents as relevant background;
however, it is not required, and lack of Montana‑specific references will not, by
itself, disadvantage an otherwise qualified proposal.
2.3 Please confirm whether core financial customer records, miscellaneous billing, and
nonutility receivables are within ERP scope, while metered utility billing and permitting
specific billing functions will be delivered by separately procured systems. The reason
for the clarification is to understand where the need for a “billing engine” outside of the
ERP which then feeds finalized calculated invoices may be needed (or potentially already
exists).
City Response: That is correct—core financial customer records, miscellaneous
billing, and nonutility receivables are within ERP scope. Utility Billing and permit-
specific billing will be procured separately.
3. Pricing, Budgets, and Cost Structure
3.1 The RFP requires all pricing to be fixed fee inclusive of travel. Is there any flexibility on this
requirement for activities that are inherently variable, such as on-site knowledge transfer
sessions where City scheduling drives the need?
City Response: The City’s intent in requiring fixed‑fee pricing inclusive of travel is to
provide cost certainty and avoid uncontrolled or ad‑hoc travel expenses. The City is
open to a controlled travel allowance or drawdown model, provided that it is clearly
defined, appropriately justified, and subject to a not‑to‑exceed amount. Any such
travel budget must be based on the Respondent’s proposed implementation
approach and should reflect what the Respondent believes will best support project
success. Travel expenses would require City pre‑approval and must comply with
reasonable cost controls (e.g., GSA or comparable public‑sector travel rates).
Respondents may propose alternative methods for managing and controlling
variable travel costs, provided they ensure transparency, predictability, and
alignment with the City’s financial controls.
3.2 The final payment holdback is a minimum of 10% per phase, released only after written
Final Acceptance following a 60-day post-go-live validation period. Does that 10% apply
to each phase independently, or is it calculated against total contract value?
City Response: The 10% holdback applies to each implementation phase
independently, not to the total contract value. As stated in the contract language,
the final milestone payment for a given phase represents no less than ten percent
(10%) of the total implementation fees for the applicable phase and is contingent
upon written Final Acceptance following the required post‑go‑live validation period.
For a single‑phase implementation, this equates to a 10% holdback of the total
implementation fees. For a multi‑phase implementation, each phase will have its
own Final Acceptance milestone and associated holdback calculated against that
phase’s implementation fees, with release occurring upon Final Acceptance of
that phase.
3.3 Would the City consider moving certain items (e.g., additional conversion years or extra
custom reports) to an optional “not-to-exceed” category to keep the core
implementation strictly fixed-fee?
City Response: The City considers the data conversion periods and reporting items
identified in the RFP to represent the minimum required scope for a successful ERP
implementation and does not intend to reduce that scope or associated data
volumes in order to achieve a lower fixed‑fee price. Respondents should assume
that the specified data (e.g., current‑year budget and required historical periods)
must be included in the base fixed‑fee implementation. The City may consider
certain incremental enhancements, such as additional historical conversion years
beyond the required scope, as optional items with clearly defined not‑to‑exceed
pricing, provided such items are strictly additive and not necessary to meet the
base requirements.
Similarly, the report inventory provided with the RFP reflects the reports currently
used by the City and is intended to communicate the information and business
outcomes the City relies upon today. As noted in the RFP, the City acknowledges
that not all existing reports may be needed or replicated in the same form in a new
ERP. Respondents should not assume a one‑to‑one delivery of each listed report;
instead, the City expects that the information represented by those reports will be
accessible through standard system reports, configurable queries, dashboards,
inquiry screens, or other base system functionality, with “custom” reports only
developed as necessary.
3.4 The RFP states a $3M budget for implementation and a $400K annual budget for software
fees. Are these funded from separate budget sources or appropriations?
City Response: Both amounts are included in an internal service fund and
allocated throughout the City to all City Departments.
3.5 If a Joint Proposal includes separate software and implementation contracts, will the City
aggregate both totals when applying the price rubric, and if so, how?
City Response: For purposes of applying the pricing evaluation rubric, the City will
evaluate the total proposed cost to the City for each proposal, regardless of
whether the solution is proposed from a single Respondent or as a Joint Proposal
with multiple software and implementation agreements. Where Respondents
submit a joint proposal, the City will aggregate the applicable implementation fees
and software subscription fees across all proposed Firms when applying the pricing
rubric.
3.6 For a multi-phase implementation, does the 10% final payment holdback apply per
phase at each go-live, or only at the conclusion of the full contract?
City Response: Please see response to 3.2.
3.7 Would the organization like to see pricing for products that aren’t outlined in scope of
work (i.e. Employee Document Management, etc.)?
City Response: Yes, the City is open to additional scope functionality, but please
be sure to note any optional expenses so as to differentiate from the core
implementation.
3.8 Does the City have an anticipated funding range or budgetary guidance that respondents
should consider when proposing solution scope and phasing?
City Response: Please see Section III.3.1 of the RFP for budget information.
3.9 Should all travel and expenses be fully embedded within fixed fee milestone pricing, with
no separate reimbursement?
City Response: Please see response to 3.1.
3.10 Will the City accept optional modules or phased capabilities if clearly identified and
separately priced?
City Response: Yes, the City will accept optional modules or phased capabilities if
they are clearly identified, separately priced, and explicitly described as optional.
The City recognizes that Respondents may offer additional capabilities beyond
those necessary to meet the City’s stated objectives and outcomes and is open to
evaluating such options where they provide measurable value.
However, the City’s intent is that proposals clearly demonstrate how the
Respondent’s solution achieves the overall goals and functional outcomes
described in the RFP to enable fair and consistent evaluation across Respondents.
Optional modules or phased capabilities must not be relied upon to meet core
functionality of a modern ERP, nor should core functionality be shifted into optional
pricing to reduce the base proposal cost. Respondents should clearly distinguish
between functionality and features included in the fixed‑fee base proposal and any
optional or phased items and describe the rationale and value of such options. The
City will evaluate optional items separately and reserves the right to elect or defer
them independent of base proposal evaluation.
4. Contractual Terms & Commercial Exceptions
4.1 Does the Key Personnel continuity requirement (replacement approval, no-cost
substitution) in Section V.4.6 apply to subcontractor staff, or only to the Primary Firm's
personnel?
City Response: The Key Personnel continuity contract terms apply to all individuals
designated as Key Personnel, regardless of whether they are employed by the
Primary Firm or another Firm in a Joint Proposal. The City’s intent is to ensure
continuity and accountability for roles that are critical to the successful delivery of
the project, based on function and responsibility, not employment relationship.
4.2 Does identifying anticipated bounded exceptions in the proposal lock in those categories,
or can additional exceptions be negotiated during SOW development? Will disclosing
more exceptions negatively affect scoring?
City Response: Identifying anticipated bounded exceptions in a proposal does not
automatically lock in those categories as approved exceptions; rather, the City is
requesting transparency to better understand areas of potential variability during
implementation. The City acknowledges that some refinement of scope,
sequencing, or controls may occur during Statement of Work (SOW) development.
However, Respondents should not expect that additional categories of bounded
exceptions will be introduced later simply due to under‑scoping or assumptions
that could reasonably have been identified during the proposal phase.
The City encourages Respondents to disclose anticipated bounded exceptions
where appropriate and doing so will not be viewed negatively in isolation. The
primary objective is to reduce information asymmetry and minimize the likelihood
of post‑award change orders driven by differing assumptions (e.g., volume,
complexity, or configuration scope). During evaluation, the City will consider the
reasonableness, clarity, and justification of proposed bounded exceptions, as well
as the extent to which Respondents leverage the provided metrics to limit
uncertainty. Respondents are expected to price the base fixed‑fee scope using the
City’s provided metrics as the baseline and to reserve bounded exceptions strictly
for areas where scope variability is genuinely outside the Respondent’s reasonable
control.
4.3 The 120-day warranty begins at Final Acceptance, which itself follows a 60-day post-go-
live validation period. Can the City confirm the effective post-go-live warranty window is
approximately 180 days, so respondents can price support coverage accurately?
City Response: Yes. Under the City’s draft Key Contract Terms, the post‑go‑live
period consists of (1) a post‑implementation validation period of not less than sixty
(60) days leading to written Final Acceptance, followed by (2) a warranty period of
not less than one hundred twenty (120) days after Final Acceptance. Accordingly,
from go‑live through the end of the warranty period, the total timeframe is
approximately 180 days, subject to the timing of Final Acceptance.
The City’s intent is that the 60‑day validation period be used to confirm the solution
meets the agreed‑upon scope and acceptance criteria and to identify and correct
configuration defects or unmet requirements at no additional cost. Likewise, the
120‑day warranty is intended to ensure deliverables and configurations conform to
the agreed scope and functional requirements; it does not require continuous
on‑site presence or proactive monitoring by the vendor, but it does require the
vendor to correct defects and reperform non‑conforming services identified during
the warranty period at no additional cost, consistent with the City’s draft terms.
4.4 May respondents submit a summary of material contract exceptions at this stage, with
detailed contractual negotiations and redlines addressed post-selection?
City Response: Yes. At this stage, the City expects Respondents to submit a
summary of material contract exceptions or concerns rather than a full set of
detailed contract redlines. The City has included its standard SaaS Agreement
(Appendix B) for review to understand where proposed solutions may diverge from
the City’s standard terms.
Respondents should clearly identify specific provisions or sections of the
agreement that they would be unable to accept or would propose to revise, along
with a brief explanation of the rationale for each exception (e.g., standard policy
constraints, risk considerations, or conflicts with the Respondent’s business
model). Simply listing section numbers or stating a general objection without
context will not be sufficient. Detailed negotiations or redlines, if needed, will be
addressed following selection; however, the City expects Respondents to disclose
all known material contractual concerns at this stage so they can be considered as
part of the evaluation process.
5. Implementation Strategy, Phasing, and Timeline
5.1 Do you prefer the new solution be delivered all at once or in phases?
City Response: The City does not have a predetermined preference for a
single‑phase (“big bang”) versus phased implementation approach. The City
recognizes that the optimal delivery strategy may vary based on solution
architecture, implementation methodology, organizational readiness, and
dependencies with related initiatives.
Respondents should recommend an implementation approach they believe is most
appropriate for the City, based on their understanding of the City’s scope,
complexity, and constraints. In doing so, Respondents should consider that there
may be timing overlap with the Utility Billing and Permitting and Licensing
implementations, as well as differing levels of staff overlap across project teams
(with greater overlap between ERP and Utility Billing than with Permitting).
Respondents should describe the rationale for their recommended approach,
including anticipated risks, benefits, dependencies, and change‑management
considerations.
5.2 Purely from a business need perspective, would the City prefer to see Finance or
HR/Payroll be deployed first?
City Response: Please see response to 5.1.
5.3 Timeline - Do you have a desired go-live? Is there anything that is influencing this desired
go-live or your desired start of November 2026?
City Response: The City would consider January 2028 as an ideal go-live date, but it
is certainly open to Respondent suggestions on what is most appropriate and
feasible. The City’s audit generally runs from August – October, which can limit
capacity of the finance team.
5.4 Have you considered a preferred go live date?
City Response: Please see response to 5.3.
5.5 Has the county considered augmenting or adding staff to allow the core team to focus
more on the ERP deployment?
City Response: The City has taken steps to support ERP implementation efforts by
hiring a Financial Management Analyst who will play a key role in project
coordination and management. The City has also made adjustments within IT
staffing to help build capacity in anticipation of the ERP initiative.
At this time, the City does not have budget allocated for additional dedicated
positions to support the ERP deployment, and the use of temporary staffing has
historically been challenging.
To help mitigate resource constraints, the City plans to align major ERP
implementation activities with periods of lower operational demand (e.g., outside of
audit and biennial budget cycles).
The City considers this initiative an organizational priority and is committed to
providing appropriate staffing, resources, and cross-departmental support to
ensure project success. Departments are expected to actively participate and
collaborate throughout the implementation process. The City is interested in
understanding how vendors can support an efficient implementation approach and
help minimize impacts on internal staff capacity.
5.6 Would the organization like to see multiple implementation options (i.e. Standard
Implementation Practices, Premium/ Turnkey Implementation, etc.)?
City Response: Yes, the City is open to multiple implementation options, but
please be sure to note any optional expenses so as to differentiate from the core
implementation.
5.7 In a multivendor environment, is the ERP implementation partner expected to lead ERP
side integration design and coordination while working collaboratively with other system
vendors and City technical staff? Is there a desire for additional Accenture teams to own
other systems that integrate with the ERP?
City Response: Yes. In a multi‑vendor environment, the City expects the ERP
implementation partner (Primary Firm) to lead ERP‑side integration design and
coordination, working collaboratively with other system vendors and City technical
staff. This includes defining ERP interface requirements, identifying dependencies
and risks, coordinating integration design and testing activities related to the ERP,
and escalating issues in a timely manner to support overall program success.
The City does not expect the ERP implementation partner to assume ownership or
delivery responsibility for other vendors’ systems or scopes of work. The City’s
objective is to establish clear integration leadership, proactive coordination, and
shared accountability across vendors—while maintaining appropriate boundaries
of responsibility—to minimize risk associated with fragmented integration efforts
and lack of coordination.
6. City Staffing, Resourcing, and Governance
6.1 Will the City provide estimates of City staff availability (FTE or percentage by phase) to
support implementation planning and fixed fee assumptions?
City Response: The City understands the importance of City staff availability to
successful implementation planning. However, the City will not provide fixed FTE or
percentage‑by‑phase commitments for specific functional areas at this stage, as
Respondents’ delivery methodologies and expectations for client participation vary
and City staffing levels may evolve over the course of the project.
Respondents shall instead identify their expected City participation in the Work
Effort attachment, along with critical timing assumptions (e.g., workshop intensity
periods, UAT, training, cutover). The City will evaluate proposed staffing
assumptions for reasonableness and alignment with a realistic municipal operating
environment and will work with the selected vendor during implementation
planning to confirm a practical resourcing plan that supports project success while
maintaining continuity of City operations.
Please see response to 5.5 as well.
7. Change Management, Communications, and Adoption
7.1 Change Management - How are internal communications currently structured and
delivered across the organization (e.g., centralized vs. departmental)?
City Response: Internal communications are delivered through a combination of
centralized and departmental channels, depending on the nature of the
information. City-wide communications are primarily delivered through weekly
emails from the City Manager, regular leadership team meetings, and monthly
meetings with management personnel. The City also utilizes its internal Intranet,
accessible by all employees, for City-wide communications.
For particularly important updates, City-wide emails are distributed to all staff. The
City anticipates leveraging these established communication channels, including
City-wide emails and leadership meetings, to support communication efforts for
the ERP replacement project.
7.2 Change Management - How familiar are the City's end-users with self-service ERP
functionality, and how frequently is it used in your current environment?
City Response: The City’s end‑users have limited but established exposure to
self‑service functionality in the current environment. Most employees regularly use
self‑service for activities such as time entry and benefits enrollment/elections.
Beyond these functions, end‑user interaction with the ERP is relatively limited. As a
result, the City anticipates that adoption of a modern ERP will represent a
meaningful expansion of self‑service capabilities for many users. Respondents
should assume varying levels of user familiarity and comfort with ERP‑based
self‑service and should describe their recommended change management,
training, and adoption strategies to support increased use of self‑service
functionality across financial, procurement, and administrative processes.
7.3 Briefly describe your organization’s culture and estimated level of resistance to
change/adoption of technology.
City Response: The City’s organizational culture reflects a mix of established
practices and growing openness to modernization. City leadership and central
departments generally recognize the need to modernize systems and processes
and are supportive of the ERP initiative as an opportunity to improve efficiency,
transparency, and long‑term sustainability.
That said, the City anticipates varying levels of comfort with change across
departments and functions. While employees are accustomed to some self‑service
functionality, many core business processes—particularly in purchasing and
procurement—have historically operated with significant flexibility and limited
system‑driven controls. The transition to standardized, system‑supported
workflows is expected to represent a meaningful change for some users and may
encounter resistance if not supported by clear communication, training, and visible
leadership reinforcement. As described in the “Procurement Change Management
and Training” Challenge to Solve, the City is seeking Respondents’
recommendations for practical change‑management and training strategies that
address these dynamics and support broad, sustained adoption of new
ERP‑enabled processes.
7.4 What internal change management, communications, and training
capabilities/resources do you have or expect to have for this project?
City Response: The City has established a foundational level of internal readiness
and awareness for this project through preparatory efforts leading up to the RFP
release, including the formation of Process Improvement Teams representing key
functional areas. The City expects to assign a dedicated Project Manager for the
ERP implementation, and many coordination, communication, and
stakeholder‑management activities will be routed through that role. The Project
Executive, Steering Committee members, and / or PIT leads may support the
change management efforts.
The City does not anticipate staffing a dedicated, full‑time Change Manager for this
project. Instead, the City expects to rely on the selected vendor’s experience and
guidance in defining and executing effective change management,
communications, and training strategies appropriate for the City’s organizational
context. Respondents should describe how they typically partner with client project
leadership to support organizational change, including recommended roles for City
staff, vendor‑provided tools and deliverables, and practical approaches for
preparing users for new processes and system adoption.
7.5 How successful have your workforce transformation initiatives been in the past? What
challenges have you experienced?
City Response: The City has not undertaken a workforce transformation as
significant as ERP replacement in many years. In implementing new systems,
software, and other technological transformations of a smaller scale, the city does
not recall a change failing due to lack of adoption. As with most organizational
change initiatives, some City projects have encountered employee resistance
initially. Over time, however, the changes were adopted and sustained, though
comfort and adoption levels varied across departments and individuals.
In 2025, the City transitioned from a monthly to a biweekly pay cycle. The City
planned for anticipated challenges including the need for additional staff time,
resistance from employees, and changes in processes within our current system
and external to the system. With biweekly pay, a common practice among
organizations, changes within Naviline and Time and Attendance were relatively
straightforward to implement, with most of the challenges being a result of some of
the City’s complex pay rules. Advanced planning and extensive City-wide and
department-specific education and communication efforts addressed employee
concerns and led to a successful transformation.
7.6 Have you conducted any stakeholder or readiness assessments related to this initiative?
If so, what were the results?
City Response: The City has not conducted a formal, organization‑wide
stakeholder or readiness assessment specific to this ERP initiative. However, over
the past approximately nine months, the City has engaged extensively with Process
Improvement Teams (PITs) representing key functional areas to document
current‑state processes, identify challenges and pain points, envision future‑state
operations, and develop functional and technical requirements that informed this
RFP.
Through this process, the City has gained a practical understanding of stakeholder
needs, areas of process variability, and potential change impacts, which is
reflected throughout the RFP—particularly in the Challenges to Solve sections. The
City anticipates that more formal change‑readiness and stakeholder impact
assessments may be conducted as part of implementation planning, with support
from the selected vendor, to further refine change‑management and training
strategies.
7.7 Have you used a Change Champion Network successfully in past initiatives?
City Response: The City has not formally implemented a Change Champion
Network in prior initiatives at an enterprise scale comparable to this ERP project.
While some departments may have leveraged informal subject‑matter leads or peer
advocates on a limited basis for past efforts, there has been no structured or
sustained Change Champion Network used consistently across the organization.
7.8 Are formal change management deliverables (e.g., stakeholder mapping,
communications planning, training coordination, readiness assessments) expected as
part of the fixed fee implementation scope?
City Response: Yes, the City expects a “core” level of change‑management
support to be included as part of the fixed‑fee implementation scope to support
user adoption and successful transition to the new ERP. The City recognizes that
some Respondents structure their offerings to include “core” change‑management
services as part of the base implementation, with additional or more intensive
“enhanced” or optional change‑management services available as add‑ons.
Respondents shall clearly distinguish between change‑management activities and
deliverables included in their fixed‑fee proposal and any optional or enhanced
services proposed separately, as well as identify what risks are managed for in an
optional offering.
8. User Counts, Licensing, Roles, and Mobile Access
8.1 Please provide the number of Financial users, categorized as follows:
Full Users: have access to all the features and functionalities of the system and can
perform any task within their role.
Team Users: Have limited access to view data and complete tasks like entering time,
requisitions, or expenses. Some managers may also be team users if they only approve
expenses or run reports, without performing accounting entries.
City Response: Because Respondents employ differing user classifications and
licensing models, the City cannot provide or validate counts by specific user type.
The City has provided overall employee counts and high‑level functional areas to
convey organizational scale and project scope, and the City’s adopted budget is
publicly available for contextual reference only to assist Respondents in
understanding the City’s structure and operational complexity. The City does not
intend for Respondents to derive precise user or licensing quantities directly from
the budget document.
Respondents are responsible for proposing an appropriate licensing model and
estimating user quantities based on their professional experience implementing
ERP solutions for comparable public‑sector organizations. All licenses necessary to
deliver the functionality described in the Respondent’s proposal shall be included
in the fixed‑fee pricing, and Respondents should assume reasonable variability in
user roles and access needs when developing their estimates.
8.2 How many estimated users of the system would there be, as following?
a. Finance/Procurement users – examples would be people in Finance/Accounting
departments who actively work in the system to do their job
b. Cashiering Users – users who process payments
c. Admin Users – responsible for system admin tasks
City Response: See the response to Question 8.1.
8.3 What are the requirements for user roles and access controls? How important is mobile
accessibility for the ERP system?
City Response: The City does not currently prescribe specific user roles or access
control definitions. The City expects the ERP to support a flexible, modern,
role‑based security model aligned with industry best practices, including the ability
to define roles by function, responsibility, and approval authority; enforce
appropriate segregation of duties; and support configurable permissions across
modules and workflows.
Mobile accessibility is considered important to the City, particularly for workflows
that benefit from timely and convenient access. Mobile capabilities—such as time
entry and approval, employee self‑service, and basic transactional and approval
workflows—will be viewed favorably. The City does not require full ERP functionality
on mobile devices but expects responsive, secure mobile access for common
self‑service and approval activities.
9. Human Resources, Payroll, and Timekeeping
9.1 Regarding the 150 seasonal workers mentioned in addition to the 540 permanent
employees, do the seasonal workers need the same HR functionality as everyone else?
Or just a subset? (for example, will they be paid via Payroll and need Learning etc.?)
City Response: Seasonal workers will need onboarding, time entry, electronic
personnel file, and electronic paystubs/tax forms functionalities.
9.2 How many employees are anticipated to need Expense Reimbursement capability?
City Response: At this time, the City has not identified a fixed number of employees
who will require direct access to Expense Reimbursement functionality. While any
employee may be eligible for reimbursement, the City anticipates that direct system
access will be role‑based and limited to employees who regularly submit
reimbursable expenses, as well as designated administrative staff who may submit
expenses on behalf of others. Respondents should assume a mixed model that
supports both self‑service expense submission and proxy entry, with the ability to
expand or restrict access over time based on City policy and operational needs.
9.3 How many unique pay rules exist across the four collective bargaining agreements? Are
any currently not supported by NaviLine and handled manually or outside the system?
City Response: The City has a number of unique and complicated pay rules across
the different employee groups. For specific descriptions, Respondents may refer to
the City’s website to review the collective bargaining agreements at
https://www.bozeman.net/departments/human-resources/collective-bargaining-
agreements.
The City’s current timekeeping system has seven overtime rules, three
compensatory time rules, a rounding procedure, a TSA roll-back policy, and three
different salary rules. There are several pay rules that are manually calculated
outside of the City’s current system.
9.4 The RFP notes the City would like to evaluate whether the ERP can replace Employee
Navigator for benefits enrollment. Is this a hard requirement or a preferred outcome? Will
the decision be made during implementation?
City Response: The ability for the ERP to support benefits enrollment and
administration in lieu of Employee Navigator is not a mandatory requirement. The
City’s preference is to reduce its overall technology footprint where practical;
therefore, native ERP functionality that could replace Employee Navigator is
considered preferable but optional.
The City anticipates evaluating this capability during the procurement process—
particularly through proposal responses, software demonstrations, and/or
discovery activities—to determine whether ERP‑based benefits functionality would
meet the City’s business and operational needs. The final decision regarding
whether to retain or replace Employee Navigator will be made prior to contract
finalization and implementation planning.
9.5 The City references both CrewSense (Fire) and "existing public safety advanced
scheduling systems" in the payroll section. Is there a separate scheduling system for
Police beyond CrewSense?
City Response: Police currently use Pace Scheduler.
9.6 How many parallel payroll runs and what success criteria are expected to be included in
the fixed-fee scope?
City Response: The City anticipates that a minimum of two (2) complete parallel
payroll runs will be required as part of the fixed‑fee implementation scope (inclusive
of a full “end‑to‑end” process from time/attendance inputs through calculation,
payroll accounting, and downstream outputs such as pay statements and
remittance/tax files). Respondents should include their recommended approach
and timeline for parallel testing, including any additional targeted parallel runs (e.g.,
off‑cycle, retro, or a specific bargaining unit) they believe are necessary based on
their experience.
Success criteria for parallel payroll will be based on reconciliation and variance
resolution, not a single accuracy percentage. At a minimum, Respondents should
assume that parallel payroll is successful when: (1) net pay matches between
legacy and new system at the employee level within agreed tolerances for rounding;
(2) earnings, deductions, and employer costs reconcile by pay group, bargaining
unit, and major pay elements; (3) tax withholding and employer tax liabilities
reconcile at the appropriate jurisdiction and accumulator levels; and (4)
payroll‑to‑GL posting (including cash, liabilities, and expense distributions)
reconciles to the expected totals. Any variances identified must be explained and
corrected prior to go‑live, and Respondents should describe the variance
thresholds, reconciliation reports, and sign‑off approach they typically use.
9.7 How many active HR records does the City maintain? Is payroll confirmed in scope, and
does the City operate a centralized payroll department? How many payroll states are
involved?
City Response: Yes, payroll is in scope. The City currently maintains approximately
540 personnel/payroll files, which will increase by approximately 150 in the summer
months with the addition of seasonal workers. The City operates a centralized
payroll department, with a bi-weekly (every other Friday) payroll schedule, and the
only current payroll state is Montana. The City has previously processed payroll for
Colorado-based employees and is interested in respondents’ functionalities in
states outside of Montana. However, this is not a priority and Respondent’s will not
be evaluated based on payroll functionality outside of Montana.
9.8 The RFP references 4 CBAs and 12 leave types. Can the City confirm the number of
unique entitlement/accrual policies that will need to be configured across union and
non-union employee groups?
City Response: The City currently has 12 leave types. Within those leave types,
there are approximately 30 different accrual policies that apply across the
employee groups.
9.9 How many years of employee records, payroll history, and job/position/salary history
does the City expect to convert? How many applicant records and open job requisitions
are in the current ATS?
City Response: The City’s expected data conversion scope for Human Resources
and Payroll is as provided in the Data Conversion Attachment. In summary, the City
expects conversion of approximately 600 active employee records and
approximately 400 terminated employee records from the last two (2) years. For
active employees, the City’s intent for “full history” is to convert relevant
effective‑dated employment data to include position, performance evaluations,
training records, and benefits and pay history (e.g., hires/rehire, job or position
changes, status changes, and salary or rate changes) necessary to support HR
administration and reporting in the new ERP; this does not require conversion of
every legacy audit log field or nonessential historical artifacts.
For Payroll, the City expects the conversion of year‑to‑date (YTD) payroll balances
and accumulators for the go‑live year of Active Employees and YTD separated
employees, including accruals, gross wages, earnings, deductions, employer
contributions, tax withholdings, garnishments, and related balances. Detailed
historical paycheck transactions beyond the go‑live year are not expected to be
converted and will be addressed through legacy read‑only access or another
historical retention strategy.
The City generally has 10 – 15 open requisitions in its ATS, but that can vary based
on seasonality and operational needs. The City does not currently anticipate
converting active requisitions or active and historical applicant records.
9.10 Do you require physical time clocks? If so, how many?
City Response: The City currently has five physical timeclocks and may be
interested in adding additional timeclocks in the future.
9.11 Do you conduct training for any learners that aren’t employees? If so, how many external
learners?
City Response: The City does not conduct training for learners that are not active
employees.
9.12 Where/How are you currently conducting training for employees (Third Party vendor,
existing courses, etc.)?
City Response: Currently, many training courses are handled within the City’s
existing learning management system (Vector Solutions), though it also delivers in-
person and virtual trainings outside of that system utilizing a combination of third-
party vendors and internal resources.
9.13 Will the City provide detailed documentation for all collective bargaining agreements,
including pay rules, differentials, overtime, and leave provisions, to support accurate
configuration and pricing?
City Response: Yes, CBAs are all publicly available on the City’s website:
https://www.bozeman.net/departments/human-resources/collective-bargaining-
agreements. The Employee Handbook and other relevant policies are also available
on the City’s website: https://www.bozeman.net/departments/human-
resources/employment-policies.
9.14 Is the City open to a phased HR and Payroll deployment approach (e.g., Core HR first,
Payroll later), or is a single, fully integrated HR/Payroll go-live expected?
City Response: The City’s preference is for a fully integrated HR/Payroll go-live
where practical, due to the operational and compliance risks associated with
running split HR and payroll systems. However, the City will consider a phased
approach if the Respondent can demonstrate that it will not introduce significant
interim complexity, duplicate entry, or risk of payroll disruption. Any phased
proposal must include a clear plan for interim data synchronization, control
processes, and cutover readiness to ensure uninterrupted payroll operations.
9.15 Is the city open to separate HRIS and ERP systems assuming functionality is met, cost is
adequate, and integrations in place? Has the city already explored any separate HRIS
systems?
City Response: The City has not previously conducted a formal evaluation of
separate HRIS solutions independent of the ERP as part of this initiative. The City is
not opposed to considering a separate HRIS solution if a Respondent can clearly
demonstrate that the proposed approach meets functional requirements, is
cost‑effective, and—most importantly—does not increase operational, integration,
or governance risk relative to a single, fully integrated ERP solution. Respondents
proposing separate HRIS and ERP platforms should describe how risks associated
with multiple systems (e.g., data synchronization, controls, reporting consistency,
software provider coordination, and long‑term maintainability) would be mitigated,
and how seamless, reliable integration would be achieved. The City’s priority is
overall solution effectiveness, sustainability, and risk management rather than
predetermined system architecture.
9.16 Does your organization currently have any degree of employee self-service? Manager
self-service? If so, please describe.
City Response: Please see response to 7.2.
10. Chart of Accounts, GL Structure, BARS, and Financial Reporting
10.1 For Montana BARS alignment, is the City expecting the new COA to be designed to map
to BARS reporting as an output, or does BARS directly dictate segment structure in the
chart of accounts?
City Response: The City is in the process of developing a preferred Chart of
Accounts structure as part of its ERP readiness efforts. The City’s objective is to
establish a functional, flexible COA that supports internal management, budgeting,
and operational reporting, while also enabling compliance with Montana BARS
reporting requirements.
At this time, the City does not expect BARS to fully dictate the structure or
segmentation of the City’s chart of accounts. In some cases, the City’s preferred
COA segments and values may align directly with BARS elements; in other cases,
the City anticipates using mapping and reporting configurations within the ERP to
produce BARS‑compliant outputs. Respondents should assume that the ERP will be
required to support both approaches—direct alignment where appropriate and
configurable mapping for state reporting—without constraining the City’s ability to
manage or evolve its internal COA structure.
10.2 Pooled cash is currently on the General Fund balance sheet. Has Finance began working
with their auditors on the transition approach, or will they be looking for the selected
vendor to lead that process?
City Response: The City has been researching this topic but will be looking to the
vendor to lead this process.
10.3 Will the Bozeman Public Library Foundation and Downtown BID share the City's ERP
instance, or require separate environments? Do they have independent payroll, HR, or
chart of accounts configurations?
City Response: The City does not require separate ledgers. The City accounts for a
portion of the Downtown Improvement District as a separate fund. The Library
Foundation does not use the City’s ERP.
10.4 How many GL entities and departments will be configured? Is multi-currency required?
City Response: Multi‑currency functionality is not required for this implementation.
With respect to General Ledger entities, the City operates as a single unit of
government and prepares consolidated financial statements. In addition to the
City’s internal departments and operational units, two discretely presented
component units—the Bozeman Public Library Foundation and the Bozeman
Downtown Business Improvement District—are included in the scope of this ERP
project, consistent with the City’s ACFR reporting structure. Respondents should
assume that the solution must be capable of supporting the City and these
component units in a manner that enables appropriate reporting and supports
consolidated and ACFR‑compliant reporting as required.
The City has approximately 25 departments, though the final definition and
structure of departments and divisions may be refined as part of the Chart of
Accounts redesign. Respondents should base their proposals on these
assumptions and describe how their solution supports flexible organizational and
reporting structures.
10.5 Regarding the mention of Three Legal Entities 1). City departments and operational units,
2). The Bozeman Public Library Foundation, 3). The Bozeman Downtown Business
Improvement District.) Please confirm whether these entities require:
- Separate ledgers, or
- Shared ledger with financial dimensions / segments?"
- Are intercompany transactions expected between these entities?
- Is there a need for consolidated financial reporting across all entities?
City Response: The City does not require separate ledgers. The City accounts for a
portion of the Downtown Improvement District as a separate fund. There are
intercompany transactions expected between these entities.
10.6 Regarding chart of accounts redesign. Please confirm whether current Chart of Accounts
follows a linear (segmented account string) structure or a matrix (dimension-based)
structure?
City Response: The City’s current environment uses a segmented chart of
accounts structure, in which transactions are recorded using a defined accounting
string composed of multiple segments (e.g., fund, organizational unit,
object/account, etc.). This structure reflects the City’s existing approach to
budgeting, accounting, and external financial reporting.
10.7 Are there specific BARS reporting requirements that must be reflected directly in the
Chart of Accounts structure, or can these be derived through reporting hierarchies and
financial segment reporting?
City Response: The City does not require that Montana BARS reporting
classifications be embedded directly into the Chart of Accounts structure. The
City’s primary objective is to establish a flexible and well‑governed COA that meets
internal management, budgeting, and operational needs, while also supporting
accurate and compliant BARS reporting.
Respondents may propose either (a) a COA structure in which certain elements
align directly with BARS classifications, or (b) a configuration in which BARS
reporting requirements are met through reporting hierarchies, mappings, or
financial segment rollups within the ERP. The City does not have a preference for
one approach over the other, provided the solution enables efficient, auditable, and
sustainable production of BARS‑compliant reports and does not constrain the
City’s ability to evolve its internal COA structure over time.
10.8 Please share the approximate number of active accounts in your current Chart of
Accounts and the overall length of the account string (number of segments)
City Response: The Current COA has approximately 6,500 active accounts,
including the pooled cash fund. Account structure is XXX-XXXX-XXX.XX-XX. The
segments breakdown as Fund, Department, Division, Activity, Sub Activity,
Element, Object.
10.9 Future Flexibility of CoA: How important is it for the new Chart of Accounts design to
support future expansion (e.g., new funds, programs, grants) without requiring structural
redesign?
City Response: Future flexibility of the Chart of Accounts is very important to the
City. The City expects the new COA design to support growth and change over time—
including the addition of new funds, programs, grants, departments, or reporting
requirements—without requiring fundamental structural redesign or disruptive
reimplementation.
11. Budgeting, FP&A, and Scenario Planning
11.1 The biennial budget challenge describes Year 2 adoption with reconciliation to the
original biennial budget. Does the City currently use any formal tool or template to
manage that reconciliation, or is it entirely manual in Excel today?
City Response: The City’s current system allows us to post the year two budget
when the biennium budget is adopted. When amendments are made at year two
adoption, we put them in the system as a budget amendment.
11.2 What level of scenario-based budgeting is required (e.g., multiple budget versions, what-
if analysis, forecasting)?
City Response: The City currently uses Excel based models to run scenarios. The
City is interested in exploring opportunities to use the selected system to create
budget versions, what-if analysis, and support forecasting.
11.3 Is budget control required (e.g., preventing overspending), and if so, at what level (fund,
department, program, project)?
City Response: Yes, budget control is required as part of the ERP solution. The City
expects the system to support both hard controls (preventing transactions that
exceed authorized budget) and soft controls (allowing transactions to proceed
while generating warnings, notifications, or approval escalations).
The City has not finalized the specific budget control level(s) at which controls will
be enforced (e.g., fund, department, program, project, or a combination thereof), as
these decisions will be evaluated as part of the Chart of Accounts redesign. The
solution should support budget control at multiple levels and provide flexibility to
configure controls based on the City’s future needs.
11.4 Is program based budgeting expected to be fully implemented at go-live, or is a phased
enablement approach (with advanced program reporting delivered post go-live)
acceptable?
City Response: The City does not expect program‑based budgeting to be
implemented at go‑live, nor does it anticipate a defined near‑term phase for full
program‑based budgeting enablement. The City recognizes that organizational,
policy, and process considerations associated with program‑based budgeting may
take multiple years to mature beyond the initial ERP implementation.
The City’s objective for this project is to establish a foundational ERP and Chart of
Accounts design that does not preclude future program‑based accounting or
budgeting if the City elects to pursue it at a later date. Respondents should assume
that any program‑based structures implemented during the initial deployment are
intended to support future flexibility, rather than to deliver complete program‑based
budgeting functionality. The City is interested in solutions that allow program‑level
tracking and reporting to be developed incrementally in the future, without requiring
structural redesign or re‑implementation of the ERP.
11.5 Is the expectation for all FP&A activities to be directly in the ERP or is there a want for a
full-fledged planning and budgeting add-on software?
City Response: The City does not have a predetermined preference for whether
FP&A, planning, and budgeting capabilities are delivered natively within the ERP or
through a separate but tightly integrated planning and budgeting solution. The City’s
focus is on achieving the business outcomes and capabilities described in the RFP,
rather than on a specific software architecture.
12. Grants, Project Accounting, and Project Tracking
12.1 The project conversion shows approximately 1,100 active projects cleansed from 2,700.
What is the source system for project transactions and supporting documentation, and
is there a data warehouse or archival system in place today or planned?
City Response: Projects are created and maintained in the existing ERP, including
supporting documentation. The City’s intention is to convert active projects only,
and to maintain historical records in a searchable database.
12.2 Are there specific grant compliance standards that the City expects the ERP grants
management functionality to explicitly support that may differ from a typical tacked
project?
City Response: The City does not have a unique or non‑standard grant compliance
framework that differs materially from typical public‑sector grant requirements,
particularly those associated with state and federal funding. The City receives
grants that are subject to applicable federal and state compliance and reporting
requirements and expects to continue complying with those requirements.
The City’s primary objective is to improve the efficiency, accuracy, and visibility of
grant management processes within the ERP, including tracking grant budgets and
expenditures, managing allowable versus unallowable costs, monitoring balances
and match requirements where applicable, supporting reporting and audit needs,
and aligning grant activity with financial and project data.
12.3 What are the key project management features required within the system (e.g., task
tracking, resource allocation, Gantt charts, etc.)?
City Response: The City is not seeking a full‑featured project management system
as part of the ERP solution (e.g., comprehensive Gantt charting, resource leveling,
etc.). Within the ERP, the City’s primary need is for basic project‑related task
tracking capabilities that support financial and administrative control, including the
ability to define key tasks or milestones, associate them with projects, set target
dates or deadlines, and monitor status for visibility and accountability.
12.4 Based on the content within the RFP, [Implementer] requests the following to more
accurately scope and plan the formal RFP. It is understood that not all these things may
be available to share prior to any engagement of work.
i. Overview of typical grant types and funding sources
ii. Sample grant budgets and compliance reporting formats
iii. Current project accounting structures (capital vs. operating)
City Response: The City has provided high‑level information throughout the RFP to
support proposal development but has not prepared detailed grant or project
accounting artifacts for distribution at this stage.
With respect to grants, the City’s grant portfolio consists primarily of federal funding
sources, with compliance and reporting requirements dictated by the specific
grantor. Grant budgets and compliance reporting are currently managed largely
outside the ERP environment, often using Excel‑based tools and grantor‑provided
reporting formats. Expenditures, receivables, and revenues are tracked in the ERP
by either a separate special revenue fund for some grants or by project codes. The
City expects that grant compliance reporting will continue to align with grantor
requirements and is seeking to improve efficiency, visibility, and integration of grant
tracking within the ERP rather than to adopt a unique or standardized grant
reporting format at this time.
Regarding project accounting, the City currently uses projects for both capital and
operating activities, including capital construction projects and purchases, as well
as certain operating initiatives. Respondents should assume a mixed portfolio of
capital and operating projects and describe how their solution supports flexible
project accounting and reporting across both use cases.
The City recognizes that additional detail in these areas may be refined during
discovery and implementation planning. Respondents should base their proposals
on the information provided in the RFP and describe any assumptions made, along
with how their proposed solution would support the City’s current practices and
desired future improvements.
13. Procurement, AP, Inventory, and Vendor Management
13.1 Regarding the requirements for Leases, can the City mention how many leases are being
managed today? are these leases managed manually or with a system?
City Response: The City currently manages one GASB 87 in which they are the
lessor and two in which they are the lessee. The city has roughly 7-10 SBITAs which
are much more time consuming than the GABS 87 leases. All leases are currently
managed manually.
13.2 Is the City expecting the central inventory to be managed within the ERP or within
Cityworks?
City Response: At this time, the City anticipates central inventory to be managed
from Cityworks. The ERP’s role in inventory is purchasing and financial accounting.
13.3 The City envisions a solution that supports punchouts. Do you have an idea of how many
punchout vendors you intent to integrate with?
City Response: The City does not currently utilize punchout integrations. At this
time, the number of punchout vendors has not been determined. The City is
exploring punchout functionality as an option to streamline and standardize
purchasing processes across departments.
Potential vendors of interest may include commonly used suppliers such as
Amazon Business, Staples, and Grainger; however, this list is not exhaustive. The
City is interested in understanding the solution’s capabilities for supporting
punchout catalogs, including ease of implementation, vendor onboarding, and
ongoing maintenance.
13.4 Functional - We understand that you have p-cards; do you have separate expense cards
that are used for employee expenses, travel, etc.?
City Response: The City has p-cards and a fuel card program through US Bank.
13.5 Are supplier self-service capabilities (vendor onboarding, profile maintenance, invoice
submission) mandatory requirements, or are they scoring preferences?
City Response: Supplier self‑service capabilities—including vendor onboarding,
supplier profile maintenance, and electronic invoice submission—are not
mandatory requirements, but they are strongly preferred. The City’s objective is to
reduce manual administrative effort, improve data accuracy, enhance controls, and
lower operational risk by empowering vendors to manage appropriate aspects of
their own information and interactions with the City.
13.6 For prevention of purchase splitting, does the City expect system enforced cumulative
controls across requisitions and purchase orders, or is alerting and reporting sufficient?
City Response: Purchase splitting monitoring, alerts, and reporting are sufficient.
14. Data Conversion, Historical Data, and Records Retention
14.1 For historical data not being converted, is the City expecting respondents to recommend
a long-term access strategy (e.g., read-only legacy access, data warehouse, document
management), or is this simply a best-practice narrative question?
City Response: The City is requesting more than a general best‑practice narrative.
Respondents should describe their recommended long‑term strategy for preserving
and accessing historical data that will not be converted into the new ERP, based on
what they have seen work successfully for comparable public‑sector clients. This
should include options such as read‑only legacy access, data warehouse/reporting
repositories, document management approaches, or other archiving methods,
along with the relative advantages, limitations, and typical cost/effort
considerations of each approach. The City anticipates that the final approach
would be refined during implementation planning; however, the City is seeking
vendor guidance now to understand recommended models, dependencies, and
implications for long-term accessibility and governance.
14.2 For GL, Budget, and Projects, the City has indicated “Current year + 2 years.” Would the
City consider converting additional historical years if it can be accommodated within the
fixed fee price?
City Response: Yes.
14.3 Is the City requesting vendor-led data cleansing services for either the HR/payroll or
finance data sets, or will the City handle data cleansing internally prior to migration?
City Response: The City does not require vendor‑led data cleansing services as
part of the base fixed‑fee implementation scope for either the HR/payroll or finance
data sets. That said, Respondents may propose data cleansing support as part of
their fixed‑fee approach or as a separately identified optional service, based on
their experience and recommended implementation methodology. If proposed,
Respondents should clearly describe the scope of any data cleansing services,
deliverables, and how those services would reduce implementation risk, improve
data quality, or streamline the migration process. The City will evaluate such
proposals based on value, clarity, and alignment with project objectives.
14.4 For historical data that will not be converted in the new system, does the City expect this
data to be accessible within the new ERP system (e.g., inquiry/reporting)?
City Response: The City is currently exploring options to store historical records
that are not planned to be converted into the new system. The City does not expect
this data to be accessible with the ERP system.
14.5 Is there a defined retention period for historical financial data that must remain
accessible (e.g., 7 years, full history)?
City Response: The City is subject to applicable records retention requirements
and will retain historical financial data and supporting documentation for at least
the minimum periods required by law, which in Montana vary by record type in
accordance with guidance issued by the Montana Secretary of State. These legal
retention requirements establish how long records must remain accessible, but
they do not require that all historical data be converted into the new ERP system.
The City anticipates meeting its records retention and public records obligations
through a combination of approaches, which may include limited data conversion,
read‑only access to legacy systems, archival or reporting repositories, or other
appropriate retention solutions. As described in the “Challenges to Solve –
Historical Data” section of the RFP, the City is seeking Respondents’
recommendations on effective and sustainable strategies for managing historical
financial data that is not converted, including ensuring continued accessibility to
records that remain subject to audits, reporting needs, and open records requests.
14.6 Do you have a need for importing historical training records and if so how many?
City Response: The City anticipates a limited and purposeful conversion of
historical training records, rather than a full migration of all prior course completion
history. The City’s priority is to ensure that the new system accurately reflects
current and operationally relevant training status, supports ongoing compliance
monitoring, and provides a strong foundation for training management moving
forward.
Respondents should assume that training history conversion will be limited to
recent training completions (e.g., current year and/or prior 1–2 years) and other
training records that remain relevant for compliance, eligibility, or audit purposes.
Older, lower‑value historical training records (e.g., one‑time or expired trainings
from prior years) may be retained through read‑only legacy access or archival
solutions rather than converted into the ERP.
The City is interested in solutions that include native or well‑integrated learning
management functionality that meets the City’s business and compliance needs.
14.7 Do you have a need for importing historical certifications & licenses? Will you need this
ongoing from external sources?
City Response: The City expects the ERP to maintain and manage employee
certifications and licenses that are relevant to job eligibility, safety, or regulatory
compliance (e.g., CDL, CPR, and other required credentials). Currently all
certifications and licenses are tracked manually outside of the ERP.
Unlike general training history, certifications and licenses are considered
high‑value, ongoing compliance data and should be fully supported within the
system. The City expects the solution to support renewal tracking, alerts, audit
reporting, and attachment of supporting documentation where applicable. Ongoing
integration with external sources may be proposed where practical, but the City is
not prescribing real‑time integrations and will evaluate recommended approaches
based on cost, complexity, and operational value.
14.8 Please confirm the expected number of historical years to be converted for Financials,
HR, and Payroll, versus retained in legacy or archival solutions.
City Response: Please see the Data Conversion attachment and response to 14.5.
14.9 Will the City accept a read-only legacy environment or reporting archive to satisfy open
records requirements for nonconverted historical data?
City Response: Yes. The City is open to using a read‑only legacy environment,
reporting archive, data warehouse, or similar solution to satisfy public records and
open records requirements for historical data that is not converted into the new
ERP. The City’s primary requirement is that such records remain accessible,
searchable, and retrievable in accordance with applicable public records, audit,
and retention requirements.
The City does not require all historical financial data to be converted into the ERP to
meet these obligations. As described in the “Challenges to Solve – Historical Data”
section of the RFP, Respondents are encouraged to describe their recommended
approach for managing and providing access to nonconverted historical data,
including the advantages, limitations, and operational considerations of read‑only
legacy access, reporting archives, or other retention solutions.
14.10 Based on the content within the RFP, [Implementer] requests the following to more
accurately scope and plan the formal RFP. It is understood that not all these things may
be available to share prior to any engagement of work.
(1) Inventory of legacy systems by functional area
(2) Historical data retention and public records requirements
City Response: As noted in the RFP, the City currently uses Naviline (9.x) for ERP
functionality. Additional systems are included in the Interfaces attachment, along
with the City’s intention to keep or replace certain legacy systems. The City’s
conversion scope is listed in section II.7.0 of the RFP, along with information in the
Data Conversions attachment.
15. Assets and Inventory
15.1 Do you require tracking of both capitalized assets and controlled (non-capitalized)
assets within the ERP?
City Response: We do not require tracking of controlled (non-capitalized) assets
within the ERP. Some controlled assets are tracked manually by departments on
spreadsheets, and some are tracked in other systems outside the ERP.
15.2 Should the ERP manage the full asset lifecycle (acquisition to disposal), or will some
stages remain in Cityworks?
City Response: The City expects the ERP to serve as the system of record for
capital assets from a financial accounting perspective, including capitalization,
depreciation, transfers, and disposal, and to support ACFR‑compliant capital asset
reporting. The City anticipates that certain operational or maintenance‑oriented
asset activities (e.g., work orders, preventive maintenance, inspections, and
operational asset tracking) may continue to be managed in Cityworks where
appropriate.
The City’s objective is to avoid duplicate asset masters and ensure clear
governance over asset data ownership. Regardless of where operational asset
management resides, the City expects that purchasing and financial transactions
associated with asset acquisition (and where applicable, disposal proceeds) will be
processed through the ERP and appropriately reflected in the ERP’s financial and
fixed asset modules.
16. Interfaces, Integrations, and Technical Architecture
16.1 The interfaces attachment lists "Future Utility Billing System" and "Future Permitting
System" as required Day 1 integrations. Since those vendors are not yet selected, how
does the City envision managing integration design and testing timelines when
dependent system contracts have not been executed?
City Response: The City’s intent is that the ERP solution support required
integrations with the future Utility Billing and Permitting and Licensing systems.
While these integrations are identified as required, the City recognizes that the
implementation timelines for the ERP, Utility Billing, and Permitting systems may
not fully align.
As a result, the City anticipates that certain integrations may be designed,
developed, or placed into production after the ERP go‑live, based on mutually
agreed sequencing and overall program readiness. Respondents shall nevertheless
include integration design, configuration, testing, and deployment effort in their
fixed‑fee pricing, based on reasonable assumptions and prior experience in
integrating ERP systems with comparable platforms.
Refinement of interface specifications, sequencing, and testing timelines will occur
after vendor selection for all systems; however, such refinement is expected to be
accommodated within the proposed scope and pricing. Deferred implementation of
an integration following ERP go‑live shall not, by itself, constitute a change in scope
or additional cost.
The City has also asked for Respondent recommendations on the timing of this
implementation with that of Utility Billing and Permitting in the Challenges to Solve
attachment.
16.2 Cityworks is listed as a bi-directional, hourly API interface. Can the City share the
Cityworks version currently in use and confirm whether they have an existing Esri GIS
license, as both affect integration architecture?
City Response: The City is currently on 15.8.9 but will be upgrading to 23.5 soon.
The city does have an existing ESRI license.
16.3 The RFP references a centralized GIS database as the system of record for geospatial
data. Is this Esri-based? What is the current state of data governance for GIS-to-ERP data
flows today?
City Response: Yes, the system of record for geospatial data is ESRI (although the
ONLY layer that is written in Code as being the authoritative source is the Zoning
layer). There is no “current state of data governance for GIS-to-ERP data flows”
EXCEPT for the GTG workflow as it pertains to addresses. That is due to the nature
of Naviline and the workflow established with the GTG tool. Otherwise, we are
pulling data out of Naviline and pushing that data into GIS (not circular) and the
authoritative “source” of the data is Naviline.
16.4 The City currently uses CrewSense for Fire scheduling. Is the expectation that the ERP
will receive time/paycode data from CrewSense via API, or will there be a hybrid where
certain employee actions (time-off requests, accrual management) move to the ERP?
City Response: The City’s objective is to eliminate duplicate data entry for Public
Safety employees and, to the extent practical, allow public safety personnel to
operate primarily within a single scheduling and time management system. The City
expects there to be a single source of truth for time and attendance–related data,
with timely and reliable data exchange between the ERP and the public safety
scheduling systems.
At this time, the City has not prescribed a fixed integration model (e.g., API‑based
time/paycode feeds versus a hybrid approach where certain actions such as
accrual management or time‑off requests occur in the ERP). Respondents should
describe their recommended approach, based on prior experience, for integrating
an ERP with a public safety scheduling system such as CrewSense to achieve an
efficient, user‑friendly workflow and eliminate dual entry. The City expects the
selected vendors to collaborate during implementation to finalize integration design
and data ownership in a manner consistent with these objectives.
16.5 For the future Permitting and Utility Billing systems (TBD), will the City share the shortlist
of potential vendors so we can confirm pre-built integration experience?
City Response: The City does not anticipate having a shortlist of potential vendors
until June 16, 2026.
16.6 Is the Cityworks integration listed in Attachment V.3.2, or is it expected as an additional
proposed interface? Who is responsible for the Cityworks side of the integration — the
City's Cityworks vendor or the ERP implementer?
City Response: Cityworks is an in‑scope interface. Respondents should include
the Cityworks integration in their proposed approach and pricing.
With respect to responsibilities, the City will assist in overall coordination between
its Cityworks vendor and the selected ERP provider (including facilitating access,
technical contacts, and any Cityworks‑side enablement required). The selected
ERP implementer will be responsible for the ERP‑side integration design,
development, configuration, testing, and deployment, and for coordinating
integration activities with the City and Cityworks vendor as needed. The City
recognizes that the ERP implementer does not control the Cityworks vendor;
therefore, the ERP implementer will not be held responsible for delays or
non‑performance attributable solely to lack of cooperation or action by the
Cityworks vendor, provided the ERP implementer has timely communicated
requirements, dependencies, and issues to the City and has used reasonable
efforts to support integration progress.
16.7 What level of integration is expected between the ERP and the GIS system (e.g., asset
location, mapping data)
City Response: The City intends for its GIS system to serve as the system of record
for parcel, address, and other geospatial data. The City’s primary objective is to
ensure that shared location-based data remains accurate and consistent across
systems while minimizing duplicate data entry and the risk of misalignment.
At a minimum, the City anticipates an integration approach that enables the ERP to
reference and validate GIS-based identifiers and attributes (e.g., parcel ID, service
location/address, and other key property characteristics needed for financial
processes and reporting). The City recognizes that deeper GIS integration (e.g.,
embedded maps, service-area validation, or bidirectional synchronization of
asset/location attributes) may be beneficial depending on the solution architecture
and business workflows. Respondents should describe their recommended
approach in the Challenges to Solve attachment, including (a) proposed integration
level(s), (b) key data elements exchanged and directionality, (c) synchronization
frequency, (d) controls to maintain data integrity, and (e) assumptions and
dependencies (e.g., GIS platform capabilities, availability of APIs/services, and City
integration tools). The City anticipates that integration design details and
sequencing will be refined during implementation planning based on final system
selection and priority workflows.
16.8 What level of integration is expected with banking partners (e.g., bank feeds, automated
reconciliation, EFT payments)
City Response: The City expects the ERP to support standard integrations with its
banking partners to enable efficient cash management, payment processing, and
bank reconciliation. At a minimum, Respondents should assume the ability to
import standard bank statement files and support bank reconciliation workflows
that match deposits and disbursements to bank activity. The City also requires
support for electronic payments (e.g., ACH/EFT) for vendor payments, payroll, and
other disbursements, including generation and transmission of payment files in
commonly used banking formats and support for positive pay and other
fraud‑prevention controls where applicable.
Automation of banking and reconciliation processes is preferred.
16.9 What information needs to be integrated both imports/exports? Would this need to be an
API or SFTP transfer?
City Response: The City has provided an Interfaces Attachment that identifies the
systems currently anticipated to integrate with the ERP and includes a high‑level
description of the data elements expected to be exchanged (imports/exports). This
attachment is intended to establish a baseline for proposal and pricing purposes
and is not intended to represent an exhaustive or final interface specification.
Respondents should use the attachment to describe their recommended
integration approach and may identify additional interface data elements they
believe are necessary based on their experience and the City’s stated functional
requirements.
While the City is not prescribing a single integration method for all interfaces, the
City’s preference is for API-based integrations where feasible, as they better
support automation, reduce manual processes, and improve data timeliness and
reliability. File-based transfers (e.g., SFTP) may be acceptable where real-time
integration is not supported or not practical due to system constraints, data
volumes, or security considerations. Respondents should propose the most
appropriate method for each interface based on the nature of the data (real‑time vs.
batch), transaction volume, security considerations, and the capabilities of the
interfacing systems.
Respondents should clearly describe the proposed directionality
(inbound/outbound/bidirectional), expected frequency, and any comments
associated with each integration.
16.10 Should respondents assume responsibility only for defining integration patterns and data
models at this stage, with detailed build effort for integrations with systems not yet
selected handled through future scoping once vendor selections are finalized?
City Response: Please see response to 16.1.
16.11 Does the City currently use or prefer a specific integration platform (iPaaS or middleware),
or should respondents propose an ERP aligned, API based integration architecture?
City Response: The City does not currently utilize or mandate a specific integration
platform (iPaaS or middleware) as part of its existing environment. The City
recognizes, however, that the anticipated solution landscape is likely to include
multiple cloud‑based systems, and that a centralized integration approach may be
beneficial to support scalability, maintainability, and governance.
Accordingly, the City is open to either (a) an iPaaS‑based architecture, particularly
where it supports low‑code/no‑code integration development and centralized
monitoring, or (b) a more direct API‑based integration approach aligned with the
proposed ERP, provided it is secure, supportable, and sustainable.
16.12 Please identify the City’s current GIS platform and preferred integration pattern (real-
time vs. batch). Additionally, which system is expected to serve as the system of record
for spatially linked asset attributes?
City Response: The City is on ArcGIS Enterprise is version 10.9.1 upgrading to 11.5
or 12.0. The City does not have a mandated preference for either real‑time or batch
integration for its ArcGIS environment. The City’s primary objective is that shared
GIS‑related information remains accurate, timely, and consistent between
systems, with clear governance over system‑of‑record responsibilities.
Respondents should describe their recommended integration pattern based on
their experience integrating ERP systems with ArcGIS, including the pros and cons
of real‑time versus batch approaches. The desire is for the ESRI Enterprise
Geospatial database would be the system of record.
16.13 Based on the content within the RFP, [Implementer] requests the following to more
accurately scope and plan the formal RFP. It is understood that not all these things may
be available to share prior to any engagement of work.
(1) High-level current state system architecture diagram
(2) List of systems requiring ERP integration
City Response: The City will not be providing a formal current‑state system
architecture diagram as part of this procurement. The City’s environment includes
multiple legacy and third‑party systems that have evolved over time, and no single
authoritative architecture diagram currently exists. Instead, the City has provided
narrative scope descriptions, the Interfaces Attachment, and “Challenges to Solve”
sections to convey the systems in use today, the types of integrations anticipated,
and the functional context necessary for proposal and pricing purposes.
The Interfaces Attachment is intended to establish a baseline for proposal and
pricing purposes and may not represent an exhaustive or final interface
specification. Respondents should use the attachment to describe their
recommended integration approach (including proposed integration method,
directionality, frequency, etc.) and may identify additional interface data elements
or integrations they believe are necessary based on their experience and the City’s
stated functional requirements. Final interface specifications and testing timelines
will be refined during implementation planning.
The City has made a good‑faith effort to identify known in‑scope integrations
through the Interfaces Attachment and supporting scope descriptions. However,
the City recognizes that additional integration needs may be identified during due
diligence, discovery, or implementation planning. If the City elects to include an
integration or interface that was not reasonably inferable from the information
provided in the RFP and was not proposed or priced by the Respondent, such work
would be treated as a change in scope and addressed through a mutually agreed
change order. This acknowledgment is not intended to relieve Respondents of the
obligation to propose and price integrations that are reasonably identifiable based
on the RFP materials provided and standard municipal ERP implementations.
17. Billing Scope, Cashiering, POS, and Payments
17.1 Can the City clarify the scope boundaries for special assessment billing? The RFP
indicates this may fall under either ERP or Utility Billing. Will a determination be made
before proposals are due for submission, or are respondents expected to propose a
recommended approach?
City Response: The City is looking for recommendations from ERP providers if the
Special Assessment functionality can be met by the proposed ERP system, or if it is
better served by a Utility Billing system. There are approximately 20,500 properties
subject to a special assessment.
17.2 Section II.4.6 includes Special Assessments and Miscellaneous Billing, which could fall
in either the ERP or the forthcoming Utility Billing system. Can the City clarify definitively
which billing functions belong in this RFP to avoid pricing overlap between proposals?
City Response: Miscellaneous Billing is a required capability of the ERP and should
be included in Respondents’ pricing and scope for this RFP. Special Assessments
must also be addressed; however, the City recognizes that special assessment
functionality may be supported either within the ERP or within the future Utility
Billing solution, depending on system capabilities and recommended architecture.
As described in the “Challenges to Solve – Special Assessments” section, the City
is seeking Respondents’ recommendations on the most effective approach for
calculating, billing, collecting, and tracking special assessments, including how this
functionality would integrate with parcel data, financial accounting, and customer
or property billing processes. Respondents should avoid duplicative pricing
assumptions across proposals and clearly describe where special assessment
functionality would reside under their recommended approach, along with any
integration considerations. The City will evaluate these recommendations as part of
the procurement process to determine the most appropriate long‑term solution.
17.3 Should bank reconciliation be fully automated based on system matching rules, or
supported with manual review workflows
City Response: The City does not require bank reconciliation to be fully automated
in all cases. However, the City’s objective is to significantly reduce the level of
manual effort currently required to complete bank reconciliations. The ERP is
expected to support configurable system matching rules, automated matching of
common transaction types, and robust exception identification and resolution
workflows.
17.4 Does the City prefer to have either/or:
a. a centralized cashiering process where all payments are made through one
software with real-time, bi-directional integration back to other software
b. decentralized where each department/software records their own payments and
updates the financial system?
If the City would like to move to a centralized cashiering approach, can you list the
applications that you would like the new cashiering application to take payments
for?
City Response: The City’s preferred direction is toward a more centralized
cashiering model, as the current environment is largely decentralized and has
introduced challenges related to consistency, reconciliation effort, visibility, and
controls. A centralized or hub‑and‑spoke approach—where payments are
processed through a common cashiering capability with timely integration back to
source systems and the ERP—is viewed as having potential advantages, provided it
supports necessary departmental workflows and system integrations.
That said, the City has not finalized a single mandated approach and is seeking
Respondents’ recommendations based on their experience. The City expects that
certain applications and departments will continue to originate transactions and
customer interactions, with payment and summary revenue data integrated
appropriately. The Interfaces Attachment identifies systems currently anticipated to
collect payments or generate receivables and includes high‑level descriptions of
the associated revenue data; this attachment should be used as the baseline for
proposal and pricing purposes.
17.5 Would the City provide us with the total number of users, including supervisors, that will
be accessing only the new Cashiering/POS module? This would be based on receiving
payments for the Financial A/R system, miscellaneous payments and any users
associated with the answer above. (Note that read-only users and daily departmental
revenue submitters are no charge.)
City Response: The City currently has 14 actual registers, but staff can also access
the cashiering module from their own computers. City wide, we have approximately
86 users of these registers or modules.
17.6 Can the City list the current POS equipment and model you would like the Cashiering
solution to integrate with or would the City like additional POS equipment to be included
in the RFP response (receipt printers, scanners, cash drawers, check imaging/MICR
devices, encrypted credit card swipe and EMV/chip/tap-to-pay devices)?
City Response: The City currently utilizes a variety of point‑of‑sale (POS) and
cashiering equipment that has been assembled over time and is not fully
standardized across departments. The City is open to Respondents proposing new
or standardized POS equipment as part of their cashiering solution, particularly
where such equipment is proven to integrate effectively with the proposed software
and would improve reliability, security, supportability, or user experience.
Respondents should clearly describe any POS hardware assumptions, supported
devices (e.g., receipt printers, scanners, cash drawers, check imaging/MICR
devices, encrypted credit card terminals with EMV/chip/tap‑to‑pay capabilities),
and whether such equipment is required, optional, or recommended.
17.7 What credit processors are the City currently using?
City Response: Converge (Elavon), Authorize.net, Civic Plus, Chase Paymentech,
Stripe, and Paya.
17.8 Would the City like the new cashiering solution to become the City’s Online Customer
Payment Portal? If so, what applications would the City like to take online payments for?
City Response: Yes, the City’s preference is for the new cashiering solution to serve
as the City’s online customer payment portal, where feasible. The City’s objective is
to provide a consistent, user‑friendly experience for customers and to reduce
fragmentation across multiple payment entry points.
The City anticipates that most applications or systems that generate receivables or
summary revenue data may ultimately support online payments through the
cashiering solution. The Interfaces Attachment identifies systems currently
anticipated to collect revenue and should be used as a baseline for proposal and
pricing purposes. The final list of applications supported for online payments, as
well as sequencing and prioritization, will be refined during Statement of Work
development based on business need, integration readiness, and overall
implementation approach.
17.9 Would the City like the cashiering solution to create an Image Cash Letter (ICL)
containing check images for deposit, and send it to your bank? If so, what bank?
City Response: At this time, the City has not mandated that the solution generate
and transmit Image Cash Letters (ICLs). The City currently works with U.S. Bank and
uses E-Deposit / Remote Deposit Capture. The City is open to solutions in which the
platform supports check imaging and ICL generation and transmits deposits
directly to the bank, provided such functionality is proven, secure, and integrates
effectively with the City’s banking processes. The final approach will be determined
during implementation planning based on cost, risk, and operational fit.
17.10 Does the City have a multi-check scanning process in place for recording checks and
invoices in batch? If not, should this be included in the response? What is the annual
volume that the City would scan using this process?
City Response: Yes, we have two E-deposit machines that work with our US Bank
account. The majority of our checks deposited are done through this process,
somewhere between 5,000-10,000 per month.
17.11 Does the City have scenarios where different departments/agencies need to submit end
of day receipt summary information? If so, would the City like to automate that?
City Response: Yes. The City has scenarios in which departments or agencies
generate end‑of‑day receipt summaries, often across different systems or points of
collection. The City’s preference is to automate the generation, consolidation, and
transmission of end‑of‑day receipt summary information to the extent practical.
17.12 For cash receipting, what are your top five issues you experience? Of those five, which is
most important and why?
City Response: (1) POS and credit card system not communicating/failing mid-
transaction. (2) No ability to email receipts directly from the system. (3) No ability to
show a customer a copy of the actual bill at the front counter (can show billing
history but not actual bill). (4) No ability for all customers to pay online--currently
some payment types can, but not all.
18. Reporting
18.1 For the many legacy reports in Attachment 3.1, is the City open to modern alternatives
(Fusion dashboards + VBCS low-code extensions) instead of one-to-one replication,
provided the business outcome is the same or better?
City Response: Yes, absolutely. The report inventory provided with the RFP reflects
the reports currently used by the City and is intended to communicate the
information and business outcomes the City relies upon today. As noted in the RFP,
the City acknowledges that not all existing reports may be needed or replicated in
the same form in a new ERP. Respondents should not assume a one‑to‑one delivery
of each listed report; instead, the City expects that the information represented by
those reports will be accessible through standard system reports, configurable
queries, dashboards, inquiry screens, or other base system functionality, with
“custom” reports only developed as necessary.
Part II: Draft Future State Maps
Accounting
Chart of Accounts
Future
Accounting
Chart of Accounts
Future
DepartmentDepartmentFinanceFinanceVersion_1.2Version_1.2
Start
Projects/
Grants
Projects/
Grants
Request new / change in
chart of account element
(Fund, Dept, etc.), add
attachments as needed
Dept. or
Finance Staff ERP
Request new / change in
chart of account element
(Fund, Dept, etc.), add
attachments as needed
Dept. or
Finance Staff ERP
Workflow
Staff ERP
Workflow
Staff ERP
Attach required documents
Dept. or
Finance Staff ERP
Attach required documents
Dept. or
Finance Staff ERP
End
Supervisor reviews, approves
and activates the new fund in
ERP
FIN Staff ERP
Supervisor reviews, approves
and activates the new fund in
ERP
FIN Staff ERP
Auto notification to
department that new
account/fund is ready to use
Auto ERP
Auto notification to
department that new
account/fund is ready to use
Auto ERP
Budget
Adjustment
Accounting
GL Transactions
Future
Accounting
GL Transactions
Future
DepartmentDepartmentFinanceFinanceVersion_1.2Version_1.2
Start
Create Recurring JE Template for
each required recurring JE
Dept. or
Finance Staff ERP
Create Recurring JE Template for
each required recurring JE
Dept. or
Finance Staff ERP
Notification of Recurring JE on
interval determined by template
Auto ERP
Notification of Recurring JE on
interval determined by template
Auto ERP
Update JE based on current
information (i.e. current
value)
Dept. or
Finance Staff ERP
Update JE based on current
information (i.e. current
value)
Dept. or
Finance Staff ERP
RecurringOne time or recurring
COA (if
needed)
End
Review / Approve JE inside
ERP system
(by Peer FIN)
Staff ERP
Review / Approve JE inside
ERP system
(by Peer FIN)
Staff ERP
Auto store transaction record
in ERP for three years
Auto ERP
Auto store transaction record
in ERP for three years
Auto ERP
Submit Journal Entry, attach
documentation
Dept. or Finance
Staff ERP
Submit Journal Entry, attach
documentation
Dept. or Finance
Staff ERP
Workflow to Review for
accuracy
Staff ERP
Workflow to Review for
accuracy
Staff ERP
One time
Accounting
Project / Grant Tracking
Future
Accounting
Project / Grant Tracking
Future
DepartmentsDepartmentsFinance/TreasuryFinance/TreasuryVersion_1.2Version_1.2
Start
Track Employee time
Employee TE System /
Payroll
Track Employee time
Employee TE System /
Payroll
CoA (if
needed)
CoA (if
needed)
Department receives
notification that the project
has been entered.
Dept. Staff ERP
Department receives
notification that the project
has been entered.
Dept. Staff ERP
Create project shell including
sources and uses info
Dept. Staff ERP
Create project shell including
sources and uses info
Dept. Staff ERP
Track revenue and expenses by coding
transactions with project / grant code
Dept. Staff ERP
Track revenue and expenses by coding
transactions with project / grant code
Dept. Staff ERP
Workflow for expenditures includes
Project / Grant Manager
Project / Grant
Manager ERP
Workflow for expenditures includes
Project / Grant Manager
Project / Grant
Manager ERP
Compile hours, expenses,
supplies of allowable
expenses
Dept. Staff ERP
Compile hours, expenses,
supplies of allowable
expenses
Dept. Staff ERP
Determine allowable /
unallowable
Role System
Determine allowable /
unallowable
Role System
Review and Validate
Fin. Staff ERP
Review and Validate
Fin. Staff ERP
Use AR process to invoice
Grantors as needed
Dept. Staff
or other ERP
Use AR process to invoice
Grantors as needed
Dept. Staff
or other ERP
Log into Grantor’s web portal
and request payment
Dept. Staff Various
Log into Grantor’s web portal
and request payment
Dept. Staff Various
AR
TRS Payment
Receipting
TRS Payment
Receipting
Create grant/project
templates
Fin. Staff ERP
Create grant/project
templates
Fin. Staff ERP
Accounting
Financial Reporting
Future
Accounting
Financial Reporting
Future
FinanceFinanceDepartmentDepartmentVersion_1.2Version_1.2
End
Create Year-End
checklist
Controller ERP
Create Year-End
checklist
Controller ERP
Download YE
trial balance(TB)
for auditors
Controller ERP
Download YE
trial balance(TB)
for auditors
Controller ERP
Prepare
preliminary
financial
statements
Controller ERP
Prepare
preliminary
financial
statements
Controller ERP
Post ACFR to
website
Controller Manual
Post ACFR to
website
Controller Manual
Delegate various
YE processes to
finance staff for
ACFR and Audit
Preparation
Controller ERP
Delegate various
YE processes to
finance staff for
ACFR and Audit
Preparation
Controller ERP
GL
Transactio
ns
GL
Transactio
ns
GL
Transactio
ns
Start
Confirm with Finance
staff all Year-end (YE) JE’s
are posted
Controller Manual
Confirm with Finance
staff all Year-end (YE) JE’s
are posted
Controller Manual
Lock PY YE
periods for GL
posting
Controller ERP
Lock PY YE
periods for GL
posting
Controller ERP
Collect Statiscal
info for the ACFR
Fin Staff#1 ERP
Collect Statiscal
info for the ACFR
Fin Staff#1 ERP
Final Approval
from City and
Auditors
Controller Manual
Final Approval
from City and
Auditors
Controller Manual
Submit ACFR to
GFOA
Controller E-mail
Submit ACFR to
GFOA
Controller E-mail
Create ACFR
Document
Comptroller ERP/Reporting
Create ACFR
Document
Comptroller ERP/Reporting
Update ACFR write
ups as needed
(MD&A,
Transmittal)
Fin. Staff ERP/
Reporting
Update ACFR write
ups as needed
(MD&A,
Transmittal)
Fin. Staff ERP/
Reporting
Update notes to
the financial
statements
Fin. Staff ERP/
Reporting
Update notes to
the financial
statements
Fin. Staff ERP/
Reporting
Enter adjusting journals or
auditor adjustments as
needed in period 13
Fin. Staff ERP
Enter adjusting journals or
auditor adjustments as
needed in period 13
Fin. Staff ERP
Once GL has been audited and
adjusted, update financial
statements for ACFR
Fin. Staff ERP/ Reporting
Once GL has been audited and
adjusted, update financial
statements for ACFR
Fin. Staff ERP/ Reporting
Update statistical
section
Fin. Staff ERP/
Reporting
Update statistical
section
Fin. Staff ERP/
Reporting
Lock (soft close) FY so
no transactions or
journals can be posted
Fin. Staff ERP
Lock (soft close) FY so
no transactions or
journals can be posted
Fin. Staff ERP
Confirm financial
statements in draft
ACFR are accurate
Fin. Staff ERP/
Reporting
Confirm financial
statements in draft
ACFR are accurate
Fin. Staff ERP/
Reporting
Finalize all
components of the
ACFR are correct
Fin. Staff ERP /
Reporting
Finalize all
components of the
ACFR are correct
Fin. Staff ERP /
Reporting
Budgeting
Operating Budget
Future
Budgeting
Operating Budget
Future
FinanceFinanceDepartmentDepartmentHRHRCity ManagerCity ManagerCity CommissionCity CommissionVersion_1.2Version_1.2
Start
Determine major
budget goals and
directives
Director System
Determine major
budget goals and
directives
Director System
Open biennial
budget data file,
Role Budget
System
Open biennial
budget data file,
Role Budget
System
Enter base O&M budget for
year 1 and 2, and current
year projections
Dept Staff Budget System
Enter base O&M budget for
year 1 and 2, and current
year projections
Dept Staff Budget System
Enter revenues,
debt, prelim
transfers
TBD Budget
System
Enter revenues,
debt, prelim
transfers
TBD Budget
System
Identify and enter budget
requests as scenarios. Require
justification and documentation.
Dept Staff Budget System
Identify and enter budget
requests as scenarios. Require
justification and documentation.
Dept Staff Budget System
Compile base budget with
revenue to determine capacity
for new requests (scenarios)
Role System
Compile base budget with
revenue to determine capacity
for new requests (scenarios)
Role System
Create base
personnel budget
HR Staff ERP/ Budget
System
Create base
personnel budget
HR Staff ERP/ Budget
System
Meeting of executive budget
team with departments as
needed
CM, Fin. Dir., Budget
Mgr., Dept. Staff Budget System
Meeting of executive budget
team with departments as
needed
CM, Fin. Dir., Budget
Mgr., Dept. Staff Budget System
Refine proposed
budget
CM, Fin. Dir,
Budget Mgr.
Budget
System
Refine proposed
budget
CM, Fin. Dir,
Budget Mgr.
Budget
System
Budget meetings,
public hearing
City
Commission System
Budget meetings,
public hearing
City
Commission System
Formally Adopt year 1 of
biennial budget, informal
approve year 2
City Commission System
Formally Adopt year 1 of
biennial budget, informal
approve year 2
City Commission System
Export or push
adopted budget
year 1 and 2 data
TBD Budget
system
Export or push
adopted budget
year 1 and 2 data
TBD Budget
system
Compile budget
document data and
write ups
TBD Budget
system
Compile budget
document data and
write ups
TBD Budget
system
Confirm personnel
costs for new
budget requests
HR Staff ERP / Budget
System
Confirm personnel
costs for new
budget requests
HR Staff ERP / Budget
System
Publish budget
document online, file as
needed
TBD Budget System,
website
Publish budget
document online, file as
needed
TBD Budget System,
website
End
Year 2 budget
Open budget data
file for year 2 of
biennial budget
TBD Budget
System
Open budget data
file for year 2 of
biennial budget
TBD Budget
System
Enter new budget
requests as
scenarios
Dept. Staff Budget
System
Enter new budget
requests as
scenarios
Dept. Staff Budget
System
Enter/update base
personnel budget
HR Staff ERP / Budget
System
Enter/update base
personnel budget
HR Staff ERP / Budget
System
Update / confirm
revenues, debt and
prelim transfers
TBD Budget
System
Update / confirm
revenues, debt and
prelim transfers
TBD Budget
System
Meeting of executive budget
team with departments as
needed
CM, Fin. Dir., Budget
Mgr., Dept. Staff Budget System
Meeting of executive budget
team with departments as
needed
CM, Fin. Dir., Budget
Mgr., Dept. Staff Budget System
Refine proposed
budget
CM, Fin. Dir,
Budget Mgr.
Budget
System
Refine proposed
budget
CM, Fin. Dir,
Budget Mgr.
Budget
System
Confirm personnel
costs for new
budget requests
HR Staff ERP / Budget
System
Confirm personnel
costs for new
budget requests
HR Staff ERP / Budget
System
Adopt year 2 of
biennial budget
City
Commission System
Adopt year 2 of
biennial budget
City
Commission System
Publish budget
document online, file as
needed
TBD Budget System,
website
Publish budget
document online, file as
needed
TBD Budget System,
website
End
Budget meetings,
public hearing
City
Commission System
Budget meetings,
public hearing
City
Commission System
Compile Year 2
budget
TBD Budget
System
Compile Year 2
budget
TBD Budget
System
Capital
Budget
Calculate prelim rates
(property taxes, enterprise
funds, special assessment
districts)
Role System
Calculate prelim rates
(property taxes, enterprise
funds, special assessment
districts)
Role System
Meet to review/
update budget
requests and rates
Role System
Meet to review/
update budget
requests and rates
Role System
Refine interfund
transfer amounts
Role System
Refine interfund
transfer amounts
Role System
Calculate prelim rates
(property taxes, enterprise
funds, special assessment
districts)
Role System
Calculate prelim rates
(property taxes, enterprise
funds, special assessment
districts)
Role System
Meet to review/
update budget
requests and rates
Role System
Meet to review/
update budget
requests and rates
Role System
Capital
Budget
Export or push
adopted budget
year 1 and 2 data
TBD Budget
system
Export or push
adopted budget
year 1 and 2 data
TBD Budget
system
Budgeting
Budget Adjustments / Amendments
Future
Budgeting
Budget Adjustments / Amendments
Future
DepartmentDepartmentFinanceFinanceCity CommissionCity CommissionVersion_1.2Version_1.2
Need for budget
change
Enter adjustment
or amendment
Dept. or
Finance Staff ERP
Enter adjustment
or amendment
Dept. or
Finance Staff ERP
Require
Commission
Approval?
Yes
Approval
City
Commission Meeting
Approval
City
Commission Meeting
No
Post budget
adjustment
Fin. Staff ERP
Post budget
adjustment
Fin. Staff ERP
Workflow based on
cost center,
amounts
Fin. and
Dept. Staff ERP
Workflow based on
cost center,
amounts
Fin. and
Dept. Staff ERP
End
Compile amendments
that require Commission
approval
Fin. Staff ERP
Compile amendments
that require Commission
approval
Fin. Staff ERP
COA
Budgeting
Capital Improvements Planning (CIP)
Future
Budgeting
Capital Improvements Planning (CIP)
Future
DepartmentsDepartmentsFinanceFinanceCity ManagerCity ManagerCity CommissionCity CommissionVersion_1.2Version_1.2
Start
Open 5-year CIP
Data file
Fin. Staff Budget
System
Open 5-year CIP
Data file
Fin. Staff Budget
System
Budget
System
Enter Projects,
attach details and
justifications
Dept. Staff Budget
System
Enter Projects,
attach details and
justifications
Dept. Staff
Compile 5-year CIP
Fin Staff.Budget
System
Compile 5-year CIP
Fin Staff.Budget
System
Enter capital
revenues
Fin. Staff Budget
System
Enter capital
revenues
Fin. Staff Budget
System
Develop Proposed
CIP
CM, Fin.
Staff
Budget
System
Develop Proposed
CIP
CM, Fin.
Staff
Budget
System
Provide feedback
on Recommended
CIP (December)
City
Commission Meeting
Provide feedback
on Recommended
CIP (December)
City
Commission Meeting
Capital
Budget
Changes based on
feedback and
updated info
Staff Budget
System
Changes based on
feedback and
updated info
Staff Budget
System
Develop Proposed
CIP
CM, Fin.
Staff
Budget
System
Develop Proposed
CIP
CM, Fin.
Staff
Budget
System
Approve CIP
(March)
City
Commission Meeting
Approve CIP
(March)
City
Commission Meeting
Budgeting
Capital Budget
Future
Budgeting
Capital Budget
Future
FinanceFinanceVersion_1.2Version_1.2
Start CIP
Pull year 1 and 2
projects into
budget file as
scenarios
Fin. Staff Budget
System
Pull year 1 and 2
projects into
budget file as
scenarios
Fin. Staff Budget
System
Operating
Budget
Biennial operating
budget
Year 2 operating
budget
Start CIP Operating
Budget
Pull the new “year
1” into budget file
Fin. Staff Budget
System
Pull the new “year
1” into budget file
Fin. Staff Budget
System
Asset Management
Asset Acquisition
Future
Asset Management
Asset Acquisition
Future
DepartmentsDepartmentsFinanceFinanceEngineering / GISEngineering / GISInsurance / RiskInsurance / RiskVersion_1.2Version_1.2
Start
Identify projects in
the budget, usually
in CIP
Role Budget
Identify projects in
the budget, usually
in CIP
Role Budget
Review payables
for qualifying asset
purchases
Fin Staff ERP
Review payables
for qualifying asset
purchases
Fin Staff ERP
Journal Entry to
reclassify expense
(either as capital or
as expense)
Fin Staff ERP
Journal Entry to
reclassify expense
(either as capital or
as expense)
Fin Staff ERP
AP
Place asset tag
sticker on vehicle/
trailer, etc.
Dept Staff ERP / Tags
Place asset tag
sticker on vehicle/
trailer, etc.
Dept Staff ERP / Tags
Asset added to
CityWorks
Automatic CityWorks
Asset added to
CityWorks
Automatic CityWorks
Inspect vehicle, confirm
compliance with bid
specs, other criteria, etc.
Dept Staff Manual
Inspect vehicle, confirm
compliance with bid
specs, other criteria, etc.
Dept Staff Manual
Brand vehicle with
stickers, etc.
Dept Staff Vendors
Brand vehicle with
stickers, etc.
Dept Staff Vendors
Record costs and
rates for internal
billing purposes
Dept Staff CityWorks
Record costs and
rates for internal
billing purposes
Dept Staff CityWorks
Add Upfits as needed
(lights, etc.), may be
capitalized
Fleet Fleet or vendors
Add Upfits as needed
(lights, etc.), may be
capitalized
Fleet Fleet or vendors
At audit time,
record CIP or new
assets (new assets)
Fin Staff ERP
At audit time,
record CIP or new
assets (new assets)
Fin Staff ERP
Private development
with capital
contribution
Project details
entered into GIS
GIS GIS
Project details
entered into GIS
GIS GIS
End of phase, provide
Finance with assets
included in
development
Engineering GIS
End of phase, provide
Finance with assets
included in
development
Engineering GIS
Estimate total value of all
contributed capital for the
year, recorded as lump sum
Fin Staff Excel / ERP
Estimate total value of all
contributed capital for the
year, recorded as lump sum
Fin Staff Excel / ERP
End
Built or
Purchased
Built
Create asset record
for construction in
progress, provide
project code
Accountant /
Controller ERP
Create asset record
for construction in
progress, provide
project code
Accountant /
Controller ERP
Projects
/ Grants Purchasing
Mark asset as in
service
Accountant ERP
Mark asset as in
service
Accountant ERP
During purchasing, identify
purchase as an asset and /
or use the project code if
component part of asset
Flag purchase as asset
during requisition,
including project code
Dept Staff ERP
Flag purchase as asset
during requisition,
including project code
Dept Staff ERP
Purchased Purchasing
Create asset record
and add asset
details
Dept Staff ERP
Create asset record
and add asset
details
Dept Staff ERP
Review and
approve, generate
asset tag number
Accountant /
Comptroller ERP
Review and
approve, generate
asset tag number
Accountant /
Comptroller ERP
Asset posts to GL
Automatic ERP
Asset posts to GL
Automatic ERP
As appropriate
Create capital asset
record
Fin Staff ERP
Create capital asset
record
Fin Staff ERP
Receive notification asset
is in service; Add to
insurance as appropriate
Risk Mgr ERP
Receive notification asset
is in service; Add to
insurance as appropriate
Risk Mgr ERP
End
Receiving
Asset Placed into
service, start
depreciation
Role System
Asset Placed into
service, start
depreciation
Role System
Budget
Adjust.
Could include streets, water,
sewer, etc. Would all be
separate capital asset records
Asset Management
Asset Lifecycle
Future
Asset Management
Asset Lifecycle
Future
FinanceFinanceDepartmentDepartmentInsurance / RiskInsurance / RiskVersion_1.2Version_1.2
Annual Asset
Inventory
Run asset report
Dept Staff ERP / AM
Run asset report
Dept Staff ERP / AM
Review and confirm
list of assets
Dept Staff ERP / AM
Review and confirm
list of assets
Dept Staff ERP / AM
No
Review and
approve; update
asset information
as needed
Accountant ERP / AM
Review and
approve; update
asset information
as needed
Accountant ERP / AM
Asset
Disp.
Asset
Disp.Lost or
damaged?Yes
Post adjusted asset
changes as
necessary
Controller ERP
Post adjusted asset
changes as
necessary
Controller ERP
Asset change Maintenance?
Expense posted
through AP process
Automatic ERP
Expense posted
through AP process
Automatic ERP
Yes
Betterment Component?
No
Yes
Associate with
parent asset
Dept Staff ERP
Associate with
parent asset
Dept Staff ERP
Receive notification;
Updated insurance as
appropriate
Risk Mgr ERP
Receive notification;
Updated insurance as
appropriate
Risk Mgr ERP
Asset Management
Depreciation
Future
Asset Management
Depreciation
Future
DepartmentDepartmentFinanceFinanceVersion_1.2Version_1.2
Include in asset record
in use date, acquisition
cost, useful life
Dept Lead ERP
Include in asset record
in use date, acquisition
cost, useful life
Dept Lead ERP
Asset value updated;
GL / JE transaction
recorded
Automatic ERP
Asset value updated;
GL / JE transaction
recorded
Automatic ERP
System calculates
depreciation
Automatic ERP
System calculates
depreciation
Automatic ERP
Asset
acquisition
Asset
acquisition
Asset Management
Asset Disposition
Future
Asset Management
Asset Disposition
Future
FinanceFinanceDepartmentDepartmentVersion_1.2Version_1.2
Asset
Transfer
Form to transfer
asset; approved by
both parties
Dept Staff ERP
Form to transfer
asset; approved by
both parties
Dept Staff ERP
Record the transfer,
including recording
accounting transaction
if remaining value
Fin Staff ERP
Record the transfer,
including recording
accounting transaction
if remaining value
Fin Staff ERP
JE, if
applicable
Asset needs
disposal
Auction Check received
Accountant
Admin System
Check received
Accountant
Admin System
Deposited in
General Fund (or
other fund)
Treasury ERP
Deposited in
General Fund (or
other fund)
Treasury ERP
Initiate disposal of
capital asset from
capitial asset
record
Dept Staff ERP
Initiate disposal of
capital asset from
capitial asset
record
Dept Staff ERP
Reviewed and
approved
Fin Staff ERP
Reviewed and
approved
Fin Staff ERP
Disposal committee
review and approve
(vehicles and
equipment)
Role Meeting
Disposal committee
review and approve
(vehicles and
equipment)
Role Meeting
Trade In
Add trade value to the
purchase of the new item to
capture full acquisition cost
Fin Staff ERP
Add trade value to the
purchase of the new item to
capture full acquisition cost
Fin Staff ERP
Record gain or loss
on disposal at year
end, if applicable
Fin Staff ERP
Record gain or loss
on disposal at year
end, if applicable
Fin Staff ERP
Auction, Trade
In, or scrap
Scrap
Dispose of item
Dept Staff Manual
Dispose of item
Dept Staff Manual
Asset
Lifecycle
Asset
Lifecycle
JE
Sell item at auction
Dept Staff Manual
Sell item at auction
Dept Staff Manual
Donating item
requires council
approval
Procure to Pay
Vendor Management
Future
Procure to Pay
Vendor Management
Future
DepartmentsDepartmentsVendor Vendor FinanceFinanceVersion_1.2Version_1.2
Start
Complete vendor registration
form
Vendor Staff Manual
Complete vendor registration
form
Vendor Staff Manual
Attach correct documents
Vendor Staff Manual
Attach correct documents
Vendor Staff Manual
Direct Vendor to website to
register
Dept. Staff Manual
Direct Vendor to website to
register
Dept. Staff Manual
Register online
Vendor Staff ERP(VSS)
Register online
Vendor Staff ERP(VSS)
Req.Req.
Review and Verify and
approve all info (w9 / TAX
ID / etc.)
Confirm no duplicate vendor
(tax ID)
Fin Staff ERP
Review and Verify and
approve all info (w9 / TAX
ID / etc.)
Confirm no duplicate vendor
(tax ID)
Fin Staff ERP
Upload all pertinent info /
including all relevant
commodity codes)
Dept. Staff ERP(VSS)
Upload all pertinent info /
including all relevant
commodity codes)
Dept. Staff ERP(VSS)
End
Validate Tax ID
Fin Staff System
Validate Tax ID
Fin Staff System
Procure to Pay
Purchase Requisition
Future
Procure to Pay
Purchase Requisition
Future
DepartmentsDepartmentsFinanceFinanceVersion_1.2Version_1.2
POPO
Purchase
amount
Pre-Encumber amount for
the purchase
Auto ERP
Pre-Encumber amount for
the purchase
Auto ERP
Auto Budget Check
Auto ERP
Auto Budget Check
Auto ERP
$25,000 –
$80,000
Start
InventoryInventory
Enter Purchasing Requisition
directly into ERP, indicating if
the purchase is for goods or
services
Dept. Staff ERP
Enter Purchasing Requisition
directly into ERP, indicating if
the purchase is for goods or
services
Dept. Staff ERP System will auto populate
most info based on Role-
Based Security (e.g.
accounting info/other)
Auto ERP
System will auto populate
most info based on Role-
Based Security (e.g.
accounting info/other)
Auto ERP
User can select vendor based
on various search criteria
(including commodity code)
Dept. Staff ERP
User can select vendor based
on various search criteria
(including commodity code)
Dept. Staff ERP
VendorVendor
New Vendor
Needed?
YES
NO
Approval
Fin. Director ERP
Approval
Fin. Director ERP
Department
workflow
Dept. Staff ERP
Department
workflow
Dept. Staff ERP
Under $10,000
At least two quotes
Dept. Staff ERP
At least two quotes
Dept. Staff ERP
$10,000 –
$25,000
Director approval
Director ERP
Director approval
Director ERP
Director approval
Director ERP
Director approval
Director ERP
Bid/
Solicitation
Over
$80,000
At least two quotes
Dept. Staff ERP
At least two quotes
Dept. Staff ERP
System checks to confirm the
Vendor’s annual spend
against procurement
thresholds
Auto ERP
System checks to confirm the
Vendor’s annual spend
against procurement
thresholds
Auto ERP
Exceptions (i.e.
Sole Source)
No
Yes
Procure to Pay
Purchase Orders (POs)
Future
Procure to Pay
Purchase Orders (POs)
Future
DepartmentDepartmentVersion_1.2Version_1.2
RequisitionRequisition
System converts Purchase
Requisition into PO
(fully encumbers $ for
purchase) using Services T&C
Auto ERP
System converts Purchase
Requisition into PO
(fully encumbers $ for
purchase) using Services T&C
Auto ERP
Services PO Sent to vendor
Auto ERP VSS
PO Sent to vendor
Auto ERP VSS
Goods or
services?
System converts Purchase
Requisition into PO
(fully encumbers $ for
purchase)
Auto ERP
System converts Purchase
Requisition into PO
(fully encumbers $ for
purchase)
Auto ERP
PO Sent to vendor
Auto ERP VSS
PO Sent to vendor
Auto ERP VSS
System converts Purchase
Requisition into PO
(fully encumbers $ for
purchase) using Goods T&C
Auto ERP
System converts Purchase
Requisition into PO
(fully encumbers $ for
purchase) using Goods T&C
Auto ERP
PO Sent to vendor
Auto ERP VSS
PO Sent to vendor
Auto ERP VSS
End
No
Goods
Written
contract?
Yes
Contract
Manage
ment
Enter Contract
Record
Dept. Staff ERP
Enter Contract
Record
Dept. Staff ERP
Records published
on public portal
Auto ERP /
Laserfiche
Records published
on public portal
Auto ERP /
Laserfiche
Procure to Pay
Change Orders
Future
Procure to Pay
Change Orders
Future
DepartmentDepartmentFinanceFinanceVersion_0Version_0
POPO
Workflow
Dept. Staff ERP/
Workflow
Workflow
Dept. Staff ERP/
Workflow
Update PO with changes
Dept. Staff ERP
Update PO with changes
Dept. Staff ERP
System auto approves
changes within policy
(increase/decrease of x% - OR
flat dollar amount)
Auto ERP
System auto approves
changes within policy
(increase/decrease of x% - OR
flat dollar amount)
Auto ERP
Provide info and supporting
documentation if needed
(e.g. new accounting info for
additional $$/ upload docs that show
the need for change/etc.
Dept. Staff ERP
Provide info and supporting
documentation if needed
(e.g. new accounting info for
additional $$/ upload docs that show
the need for change/etc.
Dept. Staff ERP
End
Over Commission
Authority?
Seek Commission approval
PUR Dir.Manual
Seek Commission approval
PUR Dir.Manual
NO
YES
Within policy
threshold
(aggregate change
order amount)
No
No
Yes
Budget Check
Auto ERP
Budget Check
Auto ERP
Contract
Yes
Records published
on public portal
Auto ERP /
Laserfiche
Records published
on public portal
Auto ERP /
Laserfiche
Procure to Pay
P-Cards
Future
Procure to Pay
P-Cards
Future
EmployeeEmployeeComptrollerComptrollerDepartmentDepartmentVersion_1.2Version_1.2
Transaction
occurs
Reconciles total of all
submitted transactions
with Bank Charge
AP ERP
Reconciles total of all
submitted transactions
with Bank Charge
AP ERP
Wire payment to
US Bank on due
date
Auto US Bank
Wire payment to
US Bank on due
date
Auto US Bank
End
Take pictures of receipts
with smartphone
(submit on the spot)
Dept. Staff Smart
Phone/ERP
Take pictures of receipts
with smartphone
(submit on the spot)
Dept. Staff Smart
Phone/ERP
Review / Approve monthly
expenses
P-CARD
Admin.
ERP/
Dashboard
Review / Approve monthly
expenses
P-CARD
Admin.
ERP/
Dashboard
Pull BAI2 file form Bank
(User defined cadence)
P-CARD
Admin.Bank/ERP
Pull BAI2 file form Bank
(User defined cadence)
P-CARD
Admin.Bank/ERP
System AUTO reconciles
purchases
Auto Bank/ERP
System AUTO reconciles
purchases
Auto Bank/ERP
System creates exception
report for all purchase that
could not match to receipts/
transactions in the P-Card
Module
Auto Bank/ERP
System creates exception
report for all purchase that
could not match to receipts/
transactions in the P-Card
Module
Auto Bank/ERP
Reach out to card holders
and address exceptions
P-CARD
Admin.Manual
Reach out to card holders
and address exceptions
P-CARD
Admin.Manual
Update transaction
to address
exception
Role ERP
Update transaction
to address
exception
Role ERP
Transaction to be
recorded to the AP
vendors
Role System
Transaction to be
recorded to the AP
vendors
Role System
Code transaction to
GL Account and
other details
Supervisory ERP
Code transaction to
GL Account and
other details
Supervisory ERP
Procure to Pay
Bids / Solicitations
Future
Procure to Pay
Bids / Solicitations
Future
DepartmentsDepartmentsClerk’s Office Clerk’s Office VendorVendorCity CommissionCity CommissionVersion_1.2Version_1.2
Project
Budgeted
Draft RFP/RFQ/
Invitation to Bid,
has selection
criteria
Dept Template
Draft RFP/RFQ/
Invitation to Bid,
has selection
criteria
Dept Template
Post city VSS Portal
and trade group
sites
Clerk Staff ERP VSS
Post city VSS Portal
and trade group
sites
Clerk Staff ERP VSS
Post Legal Ad
Clerk Staff Newspaper
Post Legal Ad
Clerk Staff Newspaper
Submit Bid/RFP/
RFQ
Vendor ERP VSS
Submit Bid/RFP/
RFQ
Vendor ERP VSS
Receive bids/
proposals
City Clerk ERP VSS
Receive bids/
proposals
City Clerk ERP VSS
Alert Eval team that
proposals are
available
City Clerk ERP
Alert Eval team that
proposals are
available
City Clerk ERP
Score individually
Eval Team ERP
Score individually
Eval Team ERP
Meet to review and
finalize
recommendation
Eval team Meeting
Meet to review and
finalize
recommendation
Eval team Meeting
RFQ?Yes
Ask for costs
Dept Lead Email
Ask for costs
Dept Lead Email
No
Notice of Award to
Commission
Dept Lead Email
Notice of Award to
Commission
Dept Lead Email
Negotiate contract
terms
Vendor and
Department Manual
Negotiate contract
terms
Vendor and
Department Manual
Approval
City
Commission
Commission
Meeting
Approval
City
Commission
Commission
Meeting
Contract
Management
Contract
Management
Publish on City
Websity
Role System
Publish on City
Websity
Role System
Publish Bid Results
on City Website
Auto Portal
Publish Bid Results
on City Website
Auto Portal
Publish RFP Results
on City Website
Auto Portal
Publish RFP Results
on City Website
Auto Portal
Send letters to
proposers with
results
Dept. Staff Email
Send letters to
proposers with
results
Dept. Staff Email
If not lowest, price
bid, document
reasons
Eval Team ERP
If not lowest, price
bid, document
reasons
Eval Team ERP
Notify vendor
Auto ERP / Portal
Notify vendor
Auto ERP / Portal
Procure to Pay
Contract Management
Future
Procure to Pay
Contract Management
Future
City CommissionCity CommissionDepartmentDepartmentCity ClerkCity ClerkLegalLegalVersion_1.2Version_1.2
Solicitation Approval
Commission Consent
Agenda
Approval
Commission Consent
Agenda
Negotiate with
Vendor
Dept Staff City form
contract
Negotiate with
Vendor
Dept Staff City form
contract
Review checklist of
documents,
approve as to form
Legal staff Paper
Review checklist of
documents,
approve as to form
Legal staff Paper
Coordinate
paperwork with
Vendor, checklist
review
Dept Staff Paper,
Docusign, etc.
Coordinate
paperwork with
Vendor, checklist
review
Dept Staff Paper,
Docusign, etc.
Distribute copies to Department,
CMO, Legal, Vendor (could be
the Notice to Proceed)
Dept Staff Docusign
Distribute copies to Department,
CMO, Legal, Vendor (could be
the Notice to Proceed)
Dept Staff Docusign
Contract is saved
(available for
public, etc.)
Dept Staff Laserfische
Contract is saved
(available for
public, etc.)
Dept Staff Laserfische
Document retention
based on value. Need to
keep non-awarded, also.
Dept Staff Laserfische
Document retention
based on value. Need to
keep non-awarded, also.
Dept Staff Laserfische
Notice of Award
sent to vendor
Dept Staff Email
Notice of Award
sent to vendor
Dept Staff Email
End
Create or confirm
contract record has
been entered.
Dept. Staff ERP
Create or confirm
contract record has
been entered.
Dept. Staff ERP
Track contract changes (term, amount,
etc.), insurance, encumbrances, bonds,
expirations, etc. in contract record
Dept. Staff ERP
Track contract changes (term, amount,
etc.), insurance, encumbrances, bonds,
expirations, etc. in contract record
Dept. Staff ERP
End
Contract
documents
retained for
specified period
Auto ERP
Contract
documents
retained for
specified period
Auto ERP
Records are
expunged after
retention period
expires
Auto?ERP
Records are
expunged after
retention period
expires
Auto?ERP
Procure to Pay
Receiving
Future
Procure to Pay
Receiving
Future
DepartmentsDepartmentsVersion_1.2Version_1.2
Start
InventoryInventory
Pull the Packing Slip / bill of
Lading
Dept. Staff Manual
Pull the Packing Slip / bill of
Lading
Dept. Staff Manual
Open package to verify all
items ordered were received
Dept. Staff Manual
Open package to verify all
items ordered were received
Dept. Staff Manual
Scan Package Slip / Bill of
Lading into ERP
Dept. Staff ERP
Scan Package Slip / Bill of
Lading into ERP
Dept. Staff ERP
End
Auto notification to staff
member who order upon
scan/upload of packing
slip
Auto ERP
Auto notification to staff
member who order upon
scan/upload of packing
slip
Auto ERP
Staff member who
purchased the items
confirms receipt (in ERP)
Various ERP
Staff member who
purchased the items
confirms receipt (in ERP)
Various ERP
Notification that goods have been
received
(i.e. ready to pay – in full or partial
depending upon count received)
Auto ERP
Notification that goods have been
received
(i.e. ready to pay – in full or partial
depending upon count received)
Auto ERP
Wherehouse inventory count
is updated
Auto ERP
Wherehouse inventory count
is updated
Auto ERP
Procure to Pay
Accounts Payable
Future
Procure to Pay
Accounts Payable
Future
DepartmentsDepartmentsVendor Vendor APAPCity CommissionCity CommissionVersion_1.2Version_1.2
Start
Send invoice to AP
and/or Department
or upload to portal
Vendor ERP VSS,
Email, mail
Send invoice to AP
and/or Department
or upload to portal
Vendor ERP VSS,
Email, mail
Store checks in safe
until next
Commission
AP Staff Safe
Store checks in safe
until next
Commission
AP Staff Safe
Approve on
Consent Agenda
Role Agenda
Approve on
Consent Agenda
Role Agenda
Checks are mailed
AP Staff Mail, or pick
up in person
Checks are mailed
AP Staff Mail, or pick
up in person
End
Prepare EAL (Expenditure
Approval List) for
Commission Agenda
AP Staff ERP
Prepare EAL (Expenditure
Approval List) for
Commission Agenda
AP Staff ERP
Upload Positive Pay
file to bank
AP Staff US Bank
Upload Positive Pay
file to bank
AP Staff US Bank
Enter invoice
information, attach
invoice / documentation
Role ERP
Enter invoice
information, attach
invoice / documentation
Role ERP
ERP VSS?Yes
Confirm data entered
correctly, receiving
match, update as needed
Dept. Staff ERP
Confirm data entered
correctly, receiving
match, update as needed
Dept. Staff ERP
No
Workflow for approval
and correct data (i.e. GL)
Staff ERP
Workflow for approval
and correct data (i.e. GL)
Staff ERP
System will not allow
duplicate invoices to be
entered
Auto ERP
System will not allow
duplicate invoices to be
entered
Auto ERP
Compile batch of fully
approved invoices for
weekly check run
AP Staff ERP
Compile batch of fully
approved invoices for
weekly check run
AP Staff ERP
Run payment process
to print checks and
create ACH file
AP Staff ERP
Run payment process
to print checks and
create ACH file
AP Staff ERP
Process approved
ACH file and
control totals
AP Staff US Bank
Process approved
ACH file and
control totals
AP Staff US Bank
Procure to Pay
Inventory
Future
Procure to Pay
Inventory
Future
DepartmentsDepartmentsVersion_1.2Version_1.2
Start
Select items to restock
Dept Staff Manual
Select items to restock
Dept Staff Manual
RequisitionRequisition
Stock falls below
minimum level
Auto ERP
Stock falls below
minimum level
Auto ERP
ReceivingReceiving
Key stock item info into system
(items, stock ID#, quantities, etc.)
Dept. Staff ERP
Key stock item info into system
(items, stock ID#, quantities, etc.)
Dept. Staff ERP
End
Inventory is
available to be used
in work orders, etc.
Auto ERP
Inventory is
available to be used
in work orders, etc.
Auto ERP
Procure to Pay
Employee Reimbursement
Future
Procure to Pay
Employee Reimbursement
Future
APAPEmployeeEmployeeDepartmentDepartmentVersion_1.2Version_1.2
Travel
Travel occurs and
collect receipts
Employee Manual
Travel occurs and
collect receipts
Employee Manual
Complete Reimbursement
form, upload receipts,
submit photo
Employee ESS
Complete Reimbursement
form, upload receipts,
submit photo
Employee ESS
Approval depending on
circumstances (may need
Finance Director)
Supervisor ERP
Approval depending on
circumstances (may need
Finance Director)
Supervisor ERP
Off
Cycle
Payroll
P Card
Receipt
Process
Expense
Eligible expense is
incurred (boots,
etc.)
Employee Manual
Eligible expense is
incurred (boots,
etc.)
Employee Manual
Request Travel
Advance for
specific travel
event
Employee ESS
Request Travel
Advance for
specific travel
event
Employee ESS
Off
Cycle
Payroll
Customer Billing
Customer File
Future
Customer Billing
Customer File
Future
DepartmentsDepartmentsFinanceFinanceVersion_1.2Version_1.2
Create customer
record
Dept Staff ERP
Create customer
record
Dept Staff ERP
Customer type
determines review
and approval routing
Asst Treasurer ERP
Customer type
determines review
and approval routing
Asst Treasurer ERP
Receive notification
customer added
Dept Staff ERP
Receive notification
customer added
Dept Staff ERP
BillingBilling
NoIn system?
Search for
customer file
Dept Staff ERP
Search for
customer file
Dept Staff ERP
Yes
Create customer
record
Asst
Treasurer ERP
Create customer
record
Asst
Treasurer ERP
Update customer
record
Dept Staff ERP
Update customer
record
Dept Staff ERP
Requires
update?
No
Yes
Activity within
last [x] years?
No change to
customer record
Automatic ERP
No change to
customer record
Automatic ERP
Customer record
becomes inactive
Automatic ERP
Customer record
becomes inactive
Automatic ERP
Yes
No
Customer Billing
Billing – Miscellaneous Receivables
Future
Customer Billing
Billing – Miscellaneous Receivables
Future
FinanceFinanceDepartmentDepartmentVersion_1.2Version_1.2
If not attached to
property, send
separate bill.
Asst.
Treasurer ERP
If not attached to
property, send
separate bill.
Asst.
Treasurer ERP
Process invoices
throughout the
month
Asst.
Treasurer ERP
Process invoices
throughout the
month
Asst.
Treasurer ERP
Send invoice to
customer with
remit information
Staff ERP, mail
Send invoice to
customer with
remit information
Staff ERP, mail
Accounts
Receivable
Link invoice to
property through GIS
integration if bill tied
to specific property
and lienable
Customer
File
Create invoice for
amount owed,
attaching backup /
documentation
Department
Staff ERP
Create invoice for
amount owed,
attaching backup /
documentation
Department
Staff ERP
Water fill station -sent quarterly also
includes customer information
Link invoice to property
through GIS integration if bill
tied to specific property and
lienable
Create invoice for
amount owed,
attaching backup /
documentation
Asst
Treasurer ERP
Create invoice for
amount owed,
attaching backup /
documentation
Asst
Treasurer ERP
Review and
approve
Asst
Treasurer ERP
Review and
approve
Asst
Treasurer ERP
Invoice created in
Third Party
System (TPS)
Create invoice for
amount owed,
attaching backup /
documentation
Department
Staff TPS
Create invoice for
amount owed,
attaching backup /
documentation
Department
Staff TPS
Send invoice to
customer with
remit information
Department
Staff TPS, mail
Send invoice to
customer with
remit information
Department
Staff TPS, mail
AR TPS
Customer Billing
Billing – City Assessments
Future
Customer Billing
Billing – City Assessments
Future
FinanceFinanceVendorVendorVersion_1.2Version_1.2
Start
Create Billing File,
Pull Billing Files
from Land
Asst.
Treasurer Naviline
Create Billing File,
Pull Billing Files
from Land
Asst.
Treasurer Naviline
Create the loan to the
property for the life of
the loan/SA
Role SA Section of
MR
Create the loan to the
property for the life of
the loan/SA
Role SA Section of
MR
In October, bill the
assessments
Asst.
Treasurer Tax Module
In October, bill the
assessments
Asst.
Treasurer Tax Module
Add accounts to
the Tax Module
Asst.
Treasurer Tax Module
Add accounts to
the Tax Module
Asst.
Treasurer Tax Module
Once balanced,
transfer balances to
tax module
Asst.
Treasurer Tax Module
Once balanced,
transfer balances to
tax module
Asst.
Treasurer Tax Module
Various bills for Sas, SIDs,
Lighting Districts, Delinquent
Charges are added to the bill
Asst. Treasurer Tax Module
Various bills for Sas, SIDs,
Lighting Districts, Delinquent
Charges are added to the bill
Asst. Treasurer Tax Module
Add valuations to
the properties
Role Tax File
Add valuations to
the properties
Role Tax File
Open Bill Cycle
Asst.
Treasurer Tax Module
Open Bill Cycle
Asst.
Treasurer Tax Module
Audit and verify to confirm billing
information is correct, balancing to
resolutions and other billing information
Treasurer Tax Module
Audit and verify to confirm billing
information is correct, balancing to
resolutions and other billing information
Treasurer Tax Module
Create PDF file and
send to local
printer
Asst.
Treasurer
Tax Module /
Email
Create PDF file and
send to local
printer
Asst.
Treasurer
Tax Module /
Email
Print bills
Vendor Email
Print bills
Vendor Email
Mail bills prior to
November 1
Role USPS
Mail bills prior to
November 1
Role USPS
End
Note: County will soon be doing the billing. Bozeman still has to calculate the amounts due to each property
Customer Billing
Accounts Receivable & Aging
Future
Customer Billing
Accounts Receivable & Aging
Future
FinanceFinanceDepartmentDepartmentCity CommissionCity CommissionCustomerCustomerVersion_1.2Version_1.2
System provides
aging report /
dashboard
Automatic ERP
System provides
aging report /
dashboard
Automatic ERP
Will stop water fill
service (or other) if
not paid.
Dept Staff Various
Will stop water fill
service (or other) if
not paid.
Dept Staff Various
Finance contact
department for
delinquency follow up
Asst Treasurer Manual
Finance contact
department for
delinquency follow up
Asst Treasurer Manual
Yes Internal
Service No
Send letter
indicating property
will be liened
Role Manual
Send letter
indicating property
will be liened
Role Manual
Resolution sending
still delinquent bills
to lien
Commission Vote / Ratify
Resolution sending
still delinquent bills
to lien
Commission Vote / Ratify
Accounts are
written off AR
Asst
Treasurer ERP
Accounts are
written off AR
Asst
Treasurer ERP
Attach to
assessment billing
Fin Staff Manual
Attach to
assessment billing
Fin Staff Manual
Receipting
Write Offs
Annual review of
small accounts
Asst
Treasurer ERP
Annual review of
small accounts
Asst
Treasurer ERP
Review and
approve delinquent
accounts for write
offs
Dept Staff ERP
Review and
approve delinquent
accounts for write
offs
Dept Staff ERP
Write off the
balance
Treasurer ERP
Write off the
balance
Treasurer ERP
End
Billing
End
Creation of invoice
creates AR (GL)
Automatic ERP
Creation of invoice
creates AR (GL)
Automatic ERP
Customer receives bill
Customer Mail; Email /
Online, In-person
Customer receives bill
Customer Mail; Email /
Online, In-person
Full payment
received?
AR relieved (GL)
Automatic ERP
AR relieved (GL)
Automatic ERP
Yes
Credit AR by
amount received,
AR remains open
Automatic ERP
Credit AR by
amount received,
AR remains open
Automatic ERP
No
End
Paid?No
Yes
TPS
Billing
Makes
payment?Yes
No
Follow up with
customer
Dept Staff Manual
Follow up with
customer
Dept Staff Manual
Tied to
property?Yes
Resend invoice as
necessary. After aging
threshold, advance to
next steps
No
< small dollar
threshold?
Draft resolution for
write offs
Treasurer Manual
Draft resolution for
write offs
Treasurer Manual
No
Yes
Review write offs
Commission Vote / Ratify
Review write offs
Commission Vote / Ratify
Customer
makes
payment?
No
Receipting
Yes
Customer Billing
Point of Sale / Receipting
Future
Customer Billing
Point of Sale / Receipting
Future
FinanceFinanceCustomerCustomerPOS SystemPOS SystemDepartmentDepartmentVersion_1.2Version_1.2
AR
Customers can pay via
autopay. New POS
likely can facilitate
autopay
Payment
type
Enter invoice
number and make
payment
Customer POS (online)
Enter invoice
number and make
payment
Customer POS (online)
Confirm invoice
number matches open
invoice
Auto POS
Confirm invoice
number matches open
invoice
Auto POS
Integration with AR /
invoice
Auto POS
Integration with AR /
invoice
Auto POS
Open invoice /
Available to
pay?
Yes Process Payment
Auto POS
Process Payment
Auto POS
No Reject payment
Role POS
Reject payment
Role POS
Receive payment
approval / receipt
Customer POS (online)
Receive payment
approval / receipt
Customer POS (online)
AR relieved
Auto ERP
AR relieved
Auto ERP
Mail / In-Person
Apply payment to
invoice (if applicable)
Cashier POS
Apply payment to
invoice (if applicable)
Cashier POS
Miscellaneous payments
recorded but not applied
to invoice
Receive receipt
Customer POS
Receive receipt
Customer POS
System records
transactions to GL
string
Automatic POS
System records
transactions to GL
string
Automatic POS
AR relieved as necessary
Each drawer is
balanced each day
Cashiers POS
Each drawer is
balanced each day
Cashiers POS
Deposit receipt
record created,
including GL info
Cashiers /
Auto ERP
Deposit receipt
record created,
including GL info
Cashiers /
Auto ERP
Checks are
electronically
deposited (scanners
in back office)
Cashiers US Bank
Scanners
Checks are
electronically
deposited (scanners
in back office)
Cashiers US Bank
Scanners
Cash and mixed
deposit brought to
bank daily
Role US Bank
Cash and mixed
deposit brought to
bank daily
Role US Bank
Run updates to
post to GL
Auto ERP
Run updates to
post to GL
Auto ERP
Online
Apply payment to
invoice (if applicable)
Cashier POS
Apply payment to
invoice (if applicable)
Cashier POS
System records
transactions to GL
string
Automatic POS
System records
transactions to GL
string
Automatic POS
Each drawer is
balanced each day
Cashiers POS
Each drawer is
balanced each day
Cashiers POS
Deposit receipt
record created,
including GL info
Cashiers /
Auto ERP
Deposit receipt
record created,
including GL info
Cashiers /
Auto ERP
Review and
approve deposit
batch
Role ERP
Review and
approve deposit
batch
Role ERP
Treasury
Bank Reconciliation
Future
Treasury
Bank Reconciliation
Future
FinanceFinanceVersion_1Version_1
BAI2 bank statements
received for all
accounts
Auto Bank / ERP
BAI2 bank statements
received for all
accounts
Auto Bank / ERP
Run rules-based
reconciliation
process
Accountant /
Auto ERP
Run rules-based
reconciliation
process
Accountant /
Auto ERP
Review exception
report; approve as
necessary
Accountant Manual /
ERP
Review exception
report; approve as
necessary
Accountant Manual /
ERP
Research errors
and correct
differences
Accountant Manual /
ERP
Research errors
and correct
differences
Accountant Manual /
ERP
Upload supporting
documentation
Accountant ERP
Upload supporting
documentation
Accountant ERP
Payment
Receipts
Payment
Receipts
Complete Journal
Entry corrections as
necessary
Accountant ERP
Complete Journal
Entry corrections as
necessary
Accountant ERP
Transactions
reconciled?No
Review and
approve; post to GL
Accountant /
Controller ERP
Review and
approve; post to GL
Accountant /
Controller ERP
Yes
Treasury
Disbursements
Future
Treasury
Disbursements
Future
FinanceFinanceVersion_1Version_1
Request for
disbursement
E.g., stipends, debt
service, refunds,
reimbursements, etc.
Initiate request for
disbursement; attach
documentation
Accountant ERP
Initiate request for
disbursement; attach
documentation
Accountant ERP
Review and approve
Controller ERP
Review and approve
Controller ERP
AP
Collect passthrough
revenue
Admin POS / ERP
Collect passthrough
revenue
Admin POS / ERP
Asset and liability
recorded
Accountant ERP
Asset and liability
recorded
Accountant ERP
Initiate payment /
disbursement
process
Accountant ERP
Initiate payment /
disbursement
process
Accountant ERP
Pass-through
Revenue
Recorded on GL
(relieve liability)
Accountant ERP
Recorded on GL
(relieve liability)
Accountant ERP
Treasury
Interest Allocation
Future
Treasury
Interest Allocation
Future
FinanceFinanceVersion_1Version_1
Record interest
earned to holding
account
Accountant ERP
Record interest
earned to holding
account
Accountant ERP
Allocate interest by
cash balance of
each eligible fund
Accountant /
Auto ERP / Excel
Allocate interest by
cash balance of
each eligible fund
Accountant /
Auto ERP / Excel
Receive bank
statement
Initiate Journal
Entry to record GL
transaction
Accountant ERP
Initiate Journal
Entry to record GL
transaction
Accountant ERP
Journal Entry
reviewed and
posted
Controller ERP
Journal Entry
reviewed and
posted
Controller ERP
Average daily balance
Grant Management
Grant Pursuit & Initiation
Future
Grant Management
Grant Pursuit & Initiation
Future
GrantsGrantsDepartmentDepartmentFinanceFinanceVersion_1.2Version_1.2
Identify funding
opportunity
Grants Mgr /
Department Manual
Identify funding
opportunity
Grants Mgr /
Department Manual
Log opportunity in
grant module,
including grant
details
Grants Mgr /
Department ERP
Log opportunity in
grant module,
including grant
details
Grants Mgr /
Department ERP
Review and
approve grant
pursuit
Grants Mgr /
Finance Dir ERP
Review and
approve grant
pursuit
Grants Mgr /
Finance Dir ERP
Complete and
submit grant
application
Grants Mgr /
Department
ERP / Grant
Portal
Complete and
submit grant
application
Grants Mgr /
Department
ERP / Grant
Portal
Close pursuit
opportunity
Grants Mgr /
Department ERP
Close pursuit
opportunity
Grants Mgr /
Department ERP
Awarded?No
End
Update pursuit as
awarded; Create
grant record
Grants Mgr /
Department ERP
Update pursuit as
awarded; Create
grant record
Grants Mgr /
Department ERP
Yes
Collaborate with dept
establish budget, create
project codes, establish
grant rules, assign grant PM
Grants Manager ERP
Collaborate with dept
establish budget, create
project codes, establish
grant rules, assign grant PM
Grants Manager ERP
If personnel, set funding
allocation / open project
code in time entry for
assigned personnel
Role ERP
If personnel, set funding
allocation / open project
code in time entry for
assigned personnel
Role ERP
No
Grant
Mgmt
Grant
Mgmt
Local funds
match?
Set up matching
codes / project
and/or allocation
Grants Mgr /
Finance Dir ERP
Set up matching
codes / project
and/or allocation
Grants Mgr /
Finance Dir ERP
Yes
Note: Could set up a project
code to track grant pursuit
time and expenses in
advance of grant award
Grant Management
Grant Management
Future
Grant Management
Grant Management
Future
DepartmentsDepartmentsGrantsGrantsFinanceFinanceVersion_1.2Version_1.2
Grant
Pursuit
Grant
Pursuit Fund
Usage
Initiate through
purchasing process,
using grant funding /
match accounting string
Department
Purchaser ERP
Initiate through
purchasing process,
using grant funding /
match accounting string
Department
Purchaser ERP
Review for
eligibility; approve
Grants
Manager ERP
Review for
eligibility; approve
Grants
Manager ERP
This could be optional or
based on thresholds
Purchases
Enter time on
timesheet using
project code
Department
Employee ERP
Enter time on
timesheet using
project code
Department
Employee ERP
Personnel
Could also be
allocation that
applies automatically
Prepare
reimbursement
request; query
project code
Department
/ Grants Mgr
ERP /
Manual
Prepare
reimbursement
request; query
project code
Department
/ Grants Mgr
ERP /
Manual
Submit
reimbursement
request
Department
/ Grants Mgr Grant Portal
Submit
reimbursement
request
Department
/ Grants Mgr Grant Portal
System creates AR from
the reimbursement
request data within the
grant record
Auto ERP
System creates AR from
the reimbursement
request data within the
grant record
Auto ERP
Receive payment,
match to AR
Accountant ERP
Receive payment,
match to AR
Accountant ERP
Grant
Close
Grant
Close
Multiyear grants or
grants that end
after City FY would
be carryforward to
next FY
Receive reimbursement
request for allowable
grant expenses
Grants Manager ERP
Receive reimbursement
request for allowable
grant expenses
Grants Manager ERP
Subrecipient activity
Grant Management
Grant Closeout
Future
Grant Management
Grant Closeout
Future
DepartmentsDepartmentsGrantsGrantsVersion_1.2Version_1.2
Grant
Mgmt
Grant
Mgmt
Deactivate grant
account and
liquidate remaining
funds, if applicable
Grants
Manager ERP
Deactivate grant
account and
liquidate remaining
funds, if applicable
Grants
Manager ERP
Run expenditure,
asset, etc. reports
Department
/ Grants Mgr ERP
Run expenditure,
asset, etc. reports
Department
/ Grants Mgr ERP
Compile and
upload grant data /
reporting
requirementsDepartment
/ Grants Mgr
ERP / Grant
Portal
Compile and
upload grant data /
reporting
requirementsDepartment
/ Grants Mgr
ERP / Grant
Portal
End
Note: Grant funded assets can be added to Capital Assets at a number of steps throughout procurement / ap processing.
Need to track asset disposition specifically relating to assets that may be disposed prior to the end of its useful life (per grant agreement, etc.)
Human Resources
Position Management
Future
Human Resources
Position Management
Future
DepartmentsDepartmentsHuman ResourcesHuman ResourcesCity Manager’s OfficeCity Manager’s OfficeFinanceFinanceVersion_1.2Version_1.2
Start
Send message to
departments
setting staffing plan
meeting
HR Director Email
Send message to
departments
setting staffing plan
meeting
HR Director Email
Complete staffing plan
(positions, reclass, pay
changes, etc.), along with
justification
Department ERP
Complete staffing plan
(positions, reclass, pay
changes, etc.), along with
justification
Department ERP
Hold Staffing Plan Meeting
(Reps from Department, HR,
City Manager, Finance); Model
scenarios
Multiple In person / ERP
(Budget)
Hold Staffing Plan Meeting
(Reps from Department, HR,
City Manager, Finance); Model
scenarios
Multiple In person / ERP
(Budget)
Review requests, develop
three year staffing plan, with
input from HR and Finance
City Manager ERP
Review requests, develop
three year staffing plan, with
input from HR and Finance
City Manager ERP
New positions will be
included in the
recommended budget
City Manager ERP
New positions will be
included in the
recommended budget
City Manager ERP
BudgetBudget
Communicate to
departments what has been
tentatively approved
HR Director Email / ERP
Communicate to
departments what has been
tentatively approved
HR Director Email / ERP
New positions created in
staffing plan, including
when position can be
recruited
HR Director ERP
New positions created in
staffing plan, including
when position can be
recruited
HR Director ERP
Recruit
ment
Recruit
ment
Mid year request
Review requests to add position
or change level of position(HR,
Finance, City Manager)
Multiple ERP / Meeting
Review requests to add position
or change level of position(HR,
Finance, City Manager)
Multiple ERP / Meeting
Review and
approve
City
Manager ERP
Review and
approve
City
Manager ERP
Crew new position / update
position information for relcass
with all relevant position details
HR Generalist ERP
Crew new position / update
position information for relcass
with all relevant position details
HR Generalist ERP
Reclass
Update employee
record for reclass
HR
Generalist ERP / PAF
Update employee
record for reclass
HR
Generalist ERP / PAF
End
Update employee
record for reclass
HR
Generalist ERP
Update employee
record for reclass
HR
Generalist ERP
If we want to keep
centralized, this process can
continue to work. Or we can
discuss a decentralized
approach.
Create position /
reclass request
with justification
Department
Manager ERP
Create position /
reclass request
with justification
Department
Manager ERP
Estimate salary
range / pay scale
for new positions
HR Director ERP
Estimate salary
range / pay scale
for new positions
HR Director ERP
Estimate salary
range / pay scale
for new position /
reclass
HR Director ERP
Estimate salary
range / pay scale
for new position /
reclass
HR Director ERP
New Position
Decision rationale can be provided as position
decision is made
PAF
New Position
New position
or reclass?
Create job profile /
class spec with all
relevant position
details
HR
Generalist ERP
Create job profile /
class spec with all
relevant position
details
HR
Generalist ERP
Reclass
PAF
Human Resources
Recruitment
Future
Human Resources
Recruitment
Future
Human ResourcesHuman ResourcesDepartment Department ApplicantApplicantVersion_1.3Version_1.3
Position
Management
Position
Management
Develop/update position
specifications (CDL,
qualifications, etc.), job
description, timeline, etc.
HR Recruiter and
Dept. Staff ERP
Develop/update position
specifications (CDL,
qualifications, etc.), job
description, timeline, etc.
HR Recruiter and
Dept. Staff ERP
Draft Recruitment
material (Ad,
announcement,
websites, etc.)
Recruiter /
Hiring Mgr ERP
Draft Recruitment
material (Ad,
announcement,
websites, etc.)
Recruiter /
Hiring Mgr ERP
Post external job
ads
HR Recruiter ERP / Job
Boards
Post external job
ads
HR Recruiter ERP / Job
Boards
Internal
posting
Yes
Post Internal only
job board
HR Recruiter ERP
Post Internal only
job board
HR Recruiter ERP
Post to public-
facing job board
HR Recruiter ERP
Post to public-
facing job board
HR Recruiter ERP
No
Create candidate profile
and apply during
application window
Applicant ERP
Create candidate profile
and apply during
application window
Applicant ERP
Reviewing – screening for
minimum qualifications
(pass/fail)
HR Recruiter ERP
Reviewing – screening for
minimum qualifications
(pass/fail)
HR Recruiter ERP
“SME Review” narrow
down applicants based on
pre-determined weighted
screening criteria
HR Recruiter &
Hiring Manager ERP
“SME Review” narrow
down applicants based on
pre-determined weighted
screening criteria
HR Recruiter &
Hiring Manager ERP
Recommend number of
candidates to interview
HR Recruiter &
Hiring Manager ERP
Recommend number of
candidates to interview
HR Recruiter &
Hiring Manager ERP
Determine applicants to
interview based on scores in
SME Review. Must take all
applicants within score bands.
Hiring Manager ERP
Determine applicants to
interview based on scores in
SME Review. Must take all
applicants within score bands.
Hiring Manager ERP
Set up phone interview
times/ dates with
interview panel
HR Recruiter ERP
Set up phone interview
times/ dates with
interview panel
HR Recruiter ERP
Receive notification to
select one of the
available interview slots
Applicant ERP
Receive notification to
select one of the
available interview slots
Applicant ERP
Set up interview times/
dates with interview
panel
HR Recruiter ERP
Set up interview times/
dates with interview
panel
HR Recruiter ERP
Receive notification to
select one of the
available interview slots
Applicant ERP
Receive notification to
select one of the
available interview slots
Applicant ERP
Yes
Phone
interview?No
Complete interview;
Record scores, average
scores, discuss candidates
Hiring Panel ERP
Complete interview;
Record scores, average
scores, discuss candidates
Hiring Panel ERP
Review scores, include
any additional scores
(e.g., veteran’s
preference)
HR Recruiter ERP
Review scores, include
any additional scores
(e.g., veteran’s
preference)
HR Recruiter ERP
Create list of top
candidate(s) for
hiring manager
HR Recruiter ERP
Create list of top
candidate(s) for
hiring manager
HR Recruiter ERP
No
Confirm top candidate (or
other, depending on
circumstances) - discussion
Hiring Manager Discussions
Confirm top candidate (or
other, depending on
circumstances) - discussion
Hiring Manager Discussions
May need to document
the reason if top scored
applicant is not selected
Hiring Manager ERP
May need to document
the reason if top scored
applicant is not selected
Hiring Manager ERP
Append all testing,
background, and
other information
to candidate
HR Recruiter ERP
Append all testing,
background, and
other information
to candidate
HR Recruiter ERP
Approve pay amount (if
not already determined)
by 3 of 4 members
Pay Committee ERP
Approve pay amount (if
not already determined)
by 3 of 4 members
Pay Committee ERP
NOTE: Pay Committee: HR Director City Manager, 2 Deputy City Managers
Redact identifiable
information, send request
to Pay Committee
HR Recruiter ERP
Redact identifiable
information, send request
to Pay Committee
HR Recruiter ERP
Create offer letter
with attachment
HR Recruiter ERP
Create offer letter
with attachment
HR Recruiter ERP
Accept offer
Applicant ERP
Accept offer
Applicant ERP
OnboardingOnboarding
Inform candidate of
physical, psych,
background
requirement
Hiring
Manager ERP; Email
Inform candidate of
physical, psych,
background
requirement
Hiring
Manager ERP; Email
Complete
necessary testing
Applicant Various
Complete
necessary testing
Applicant Various
Medical, Psych results
provided; Run Police
Background
PD Staff E-Soft
Medical, Psych results
provided; Run Police
Background
PD Staff E-Soft
Police sworn positions: Police Chief
presents candidates after screening to
Police Commission (resident commission)
Police Chief Meeting
Police sworn positions: Police Chief
presents candidates after screening to
Police Commission (resident commission)
Police Chief Meeting
In person
interview Yes
Phone Interview (scored)
& Select candidates to
invite to in person
interview
HR Recruiter &
Hiring Manager ERP
Phone Interview (scored)
& Select candidates to
invite to in person
interview
HR Recruiter &
Hiring Manager ERP
Indeed, HootSuite,
Handshake, etcCreate job requisition
Dept Manager /
HR Manager ERP
Create job requisition
Dept Manager /
HR Manager ERP
Ability to apply as “guest”
Including preferred scoring
(e.g., veteran)Confirm preferred
candidate(s) to
send offer
Hiring
Manager ERP
Confirm preferred
candidate(s) to
send offer
Hiring
Manager ERP
Draft Pay Request
(justification for
salary)
HR Recruiter ERP
Draft Pay Request
(justification for
salary)
HR Recruiter ERP
For non-rep position
Background for all
non-Police
HR Recruiter Accurate
Background for all
non-Police
HR Recruiter Accurate
May run additional
checks, tests
Send notification to
applicant of start
date and pre-work
HR Recruiter ERP
Send notification to
applicant of start
date and pre-work
HR Recruiter ERP
Confirm acceptance
and start date
Applicant ERP
Confirm acceptance
and start date
Applicant ERP
Draft conditional
offer
Hiring
Manager ERP
Draft conditional
offer
Hiring
Manager ERP
Public Safety?
HR drafts fire
conditional offer
Yes
Accept offer
Applicant ERP
Accept offer
Applicant ERP
Create Pay Request
with final pay offer
Hiring
Manager ERP
Create Pay Request
with final pay offer
Hiring
Manager ERP
Draft final offer
HR Recruiter ERP
Draft final offer
HR Recruiter ERP
Accept Final Offer
Applicant ERP
Accept Final Offer
Applicant ERP
If applied as guest, would need to
create profile to be uploaded to ERP
Human Resources
Onboarding
Future
Human Resources
Onboarding
Future
Human ResourcesHuman ResourcesEmployeeEmployeePayrollPayrollDepartmentDepartmentVersion_1.2Version_1.2
RecruitmentRecruitment
Assign tasks for to
complete before start
date (IT, keys, etc.)
Hiring
Manager ERP
Assign tasks for to
complete before start
date (IT, keys, etc.)
Hiring
Manager ERP
Complete
paperwork and
tasks
Employee ERP
Complete
paperwork and
tasks
Employee ERP
Process I-9 and
other employee
paperwork
HR
Generalist ERP
Process I-9 and
other employee
paperwork
HR
Generalist ERP
Notify employee of
start date, paperwork
to complete
HR Rectuiter ERP
Notify employee of
start date, paperwork
to complete
HR Rectuiter ERP
Start on Monday or
Wednesday
Employee In-Person
Start on Monday or
Wednesday
Employee In-Person
Review Benefit
Package
HR
Generalist In-Person
Review Benefit
Package
HR
Generalist In-Person
Enter information to
third-party systems (e.g.,
E Verify, E-Pass, etc.)
HR Generalist Multiple
Enter information to
third-party systems (e.g.,
E Verify, E-Pass, etc.)
HR Generalist Multiple
Schedule Benefits
Appointment (one on one,
cc employee’s supervisor)
HR Generalist Outlook
Schedule Benefits
Appointment (one on one,
cc employee’s supervisor)
HR Generalist Outlook
Enter / review add pays,
W-4, benefits, accruals,
etc.
Payroll /
Automatic ERP
Enter / review add pays,
W-4, benefits, accruals,
etc.
Payroll /
Automatic ERP
Assigned assets (IT tracks
cell phones). Add to
Employee File
Department ERP, RMS (Police)
or other
Assigned assets (IT tracks
cell phones). Add to
Employee File
Department ERP, RMS (Police)
or other
Contact Target Solutions to
create “child site” for
department’s LMS
HR Generalist Target Solutions
Contact Target Solutions to
create “child site” for
department’s LMS
HR Generalist Target Solutions
Complete new
employee
onboarding tasks
Department ERP /
Manual
Complete new
employee
onboarding tasks
Department ERP /
Manual
Review employee
documents / tasks
HR
Generalist ERP
Review employee
documents / tasks
HR
Generalist ERP
Convert applicant
file to Employee file
HR
Generalist ERP
Convert applicant
file to Employee file
HR
Generalist ERP
BenefitsBenefits
If LMS moves to ERP, this step
would not be necessary
Employee
File
Employee
File
Human Resources
Employee File
Future
Human Resources
Employee File
Future
EmployeeEmployeeHuman ResourcesHuman ResourcesVersion_1.2Version_1.2
Employee fills out
tax forms, I9, direct
deposit info, etc.
Employee ERP
Employee fills out
tax forms, I9, direct
deposit info, etc.
Employee ERP
Information to
update
Self-service update
personal information,
add documents
Employee ERP
Self-service update
personal information,
add documents
Employee ERP
Review and
approve
HR / Payroll ERP
Review and
approve
HR / Payroll ERP
Confirm receipt
of assigned
assets
Employee ERP
Confirm receipt
of assigned
assets
Employee ERP
OnboardingOnboarding
Trainings, personnel actions, evaluations,
discipline records, etc. will all be added to
the Employee File when completed.
Human Resources
Personnel Actions
Future
Human Resources
Personnel Actions
Future
DepartmentsDepartmentsHuman ResourcesHuman ResourcesEmployeeEmployeeCity ManagerCity ManagerVersion_1.2Version_1.2
Other PAs
Position
Management
Position
Management
Initiate PA by type, include
changes (new position,
salary, status, etc.) adding
documentation as
necessary
Dept Mgr / HR ERP
Initiate PA by type, include
changes (new position,
salary, status, etc.) adding
documentation as
necessary
Dept Mgr / HR ERP
Separation
Type
Submit
resignation letter
ERP
Submit
resignation letter
ERP
Voluntary
Receive resignation;
Review/approve;
provide comments
HR ERP
Receive resignation;
Review/approve;
provide comments
HR ERP
Process
termination
HR ERP
Process
termination
HR ERP
Receive offboarding
task list
ERP
Receive offboarding
task list
ERP
Receive Cobra
information
Automatic
Receive Cobra
information
Automatic
Initiate termination;
include
documentation
HR /
Supervisor ERP
Initiate termination;
include
documentation
HR /
Supervisor ERP
Involuntary
Validate PAF details,
set effective date.
HR ERP
Validate PAF details,
set effective date.
HR ERP
Backfill?Yes
End
No
Initiate offboarding
task list to multiple
stakeholders
HR ERP
Initiate offboarding
task list to multiple
stakeholders
HR ERP
Employee
File
Including transfer,
promotion, pay
change, LOA, etc.
Pay changes will occur
automatically based
on new rate and
effective date
Review and approve
for finances / budget,
if applicable
HR Director /
City Manager ERP
Review and approve
for finances / budget,
if applicable
HR Director /
City Manager ERP
Human Resources
Personnel Evaluations
Future
Human Resources
Personnel Evaluations
Future
Human ResourcesHuman ResourcesDepartmentsDepartmentsEmployeeEmployeeVersion_1.2Version_1.2
Configure evaluation
notification based
on dates
HR Manager ERP
Configure evaluation
notification based
on dates
HR Manager ERP
Receive notification
to complete
appraisal
Manager ERP
Receive notification
to complete
appraisal
Manager ERP
Complete appraisal
by deadline
Manager ERP
Complete appraisal
by deadline
Manager ERP
Receive notification
appraisal complete;
Discuss appraisal
ERP
Receive notification
appraisal complete;
Discuss appraisal
ERP
Meets
standards?
Yes
Employee
File
Employee
File
Possible initiation of
performance
improvement plan
HR / Manager ERP
Possible initiation of
performance
improvement plan
HR / Manager ERP
No
Date driven
evaluations
Configure evaluation
templates
HR Generalist /
Manager ERP
Configure evaluation
templates
HR Generalist /
Manager ERP
Ad-hoc / Goal
setting Develop check-in
schedule; document
HR Manager /
Employee ERP
Develop check-in
schedule; document
HR Manager /
Employee ERP
Acknowledgement
of review
ERP
Acknowledgement
of review
ERP
Personnel
Action
Personnel
Action
Employee receives
scheduled step
increase
HR Manager ERP
Employee receives
scheduled step
increase
HR Manager ERP
Complete self
evaluation, if
applicable
ERP
Complete self
evaluation, if
applicable
ERP
Human Resources
Benefit Management
Current
Human Resources
Benefit Management
Current
EmployeeEmployeeHR HR PayrollPayrollVersion_2.0Version_2.0
Start
Receive Rates from
MMIA and create
rate sheet
Sr HR
Generalist MMIA
Receive Rates from
MMIA and create
rate sheet
Sr HR
Generalist MMIA
Health Insurance
Committee on rates
votes
Committee Meeting
Health Insurance
Committee on rates
votes
Committee Meeting
Load rates and plan
info
Sr HR
Generalist ERP
Load rates and plan
info
Sr HR
Generalist ERP
Kick off Open
Enrollment May 15
– June 15
Sr HR
Generalist ERP
Kick off Open
Enrollment May 15
– June 15
Sr HR
Generalist ERP
Elections / deductions
sent to payroll
Automatic ERP
Elections / deductions
sent to payroll
Automatic ERP
Employees makes
elections and
provides required
documentation
Employee ERP
Employees makes
elections and
provides required
documentation
Employee ERP
Health Insurance &
Life Insurance
Submit to MMIA
via JotForm
SR HR
Generalist JotForm
Health Insurance &
Life Insurance
Submit to MMIA
via JotForm
SR HR
Generalist JotForm
HSA Enrolled
online, or
elsewhere
Payroll Optum
fiancial
HSA Enrolled
online, or
elsewhere
Payroll Optum
fiancial
Medical Flex and
Dependent Care Flex
entered
Payroll Allegiance
Medical Flex and
Dependent Care Flex
entered
Payroll Allegiance
Elect gym
membership and
provide info into
form
Employee ERP
Elect gym
membership and
provide info into
form
Employee ERP
Payroll
Processing
Life Event
Note: Employees can bring their old HSA. New HSAs established by Bozeman are Optum Financial
Integrate with providers
(e.g., MetLife and Mutual
of Omaha)
OnboardingOnboarding
Review and
approve elections
Sr HR
Generalist ERP
Review and
approve elections
Sr HR
Generalist ERP
Configure plan
dependences
Sr HR
Generalist ERP
Configure plan
dependences
Sr HR
Generalist ERP
Employee
File
Human Resources
Trainings / Certifications
Future
Human Resources
Trainings / Certifications
Future
Human ResourcesHuman ResourcesDepartments Departments EmployeeEmployeeVersion_1.2Version_1.2
BZN Delivered
Trainings
Develop training
plans
HR and Dept
Managers
Consultative
meeting
Develop training
plans
HR and Dept
Managers
Consultative
meeting
Identify trainers,
facilities, schedules,
etc.
LMS
Coordinator ERP / LMS
Identify trainers,
facilities, schedules,
etc.
LMS
Coordinator ERP / LMS
Training type
Develop content &
materials; Define
prerequisites
LMS
Coordinator ERP / LMS
Develop content &
materials; Define
prerequisites
LMS
Coordinator ERP / LMS
Purchase and
download training
content
LMS
Coordinator ERP / LMS
Purchase and
download training
content
LMS
Coordinator ERP / LMS
Developed
Purchased
Define
prerequisites
LMS
Coordinator ERP / LMS
Define
prerequisites
LMS
Coordinator ERP / LMS
Assign trainer(s),
location, schedule,
class size, etc.
LMS
Coordinator ERP / LMS
Assign trainer(s),
location, schedule,
class size, etc.
LMS
Coordinator ERP / LMS
Create course
catalogue
LMS
Coordinator ERP / LMS
Create course
catalogue
LMS
Coordinator ERP / LMS
Open registration
LMS
Coordinator ERP / LMS
Open registration
LMS
Coordinator ERP / LMS
Receive notification of
available courses /
check course catalog
Employee ERP / LMS
Receive notification of
available courses /
check course catalog
Employee ERP / LMS
Register for
course / assigned
registration
Employee ERP / LMS
Register for
course / assigned
registration
Employee ERP / LMS
Waitlisted?
Confirm
registration
LMS
Coordinator ERP / LMS
Confirm
registration
LMS
Coordinator ERP / LMS
No
Added to waitlist
Automatic ERP / LMS
Added to waitlist
Automatic ERP / LMS
Spot opens?Yes
Yes
End No
Course registration
closes
Automatic ERP / LMS
Course registration
closes
Automatic ERP / LMS
Course type
Complete course
online and pass
exam
Employee ERP / LMS
Complete course
online and pass
exam
Employee ERP / LMS
Virtual
Open class and take
attendance
Instructor In-person &
ERP / LMS
Open class and take
attendance
Instructor In-person &
ERP / LMS
In
Person
Students complete
course; Record
grade / completion
Instructor In-person &
ERP / LMS
Students complete
course; Record
grade / completion
Instructor In-person &
ERP / LMS
Review and
approve course
completion
Auto / LMS
Coordinator ERP / LMS
Review and
approve course
completion
Auto / LMS
Coordinator ERP / LMS
Course added to
employee file
Automatic ERP / LMS
Course added to
employee file
Automatic ERP / LMS
Employee
File
Notification of
expiring
certification
Outside Training
Complete course and
pass course
Employee Outside class /
system
Complete course and
pass course
Employee Outside class /
system
No Impact pay?
Yes
Personnel
Action
Receive notification of
expiring certification
Employee Outside class /
system
Receive notification of
expiring certification
Employee Outside class /
system
HR and supervisor can also
receive notifications
Add new training
record; upload
documentation
Employee Outside class /
system
Add new training
record; upload
documentation
Employee Outside class /
system
Review and
approve course
completion
Supervisor ERP / LMS
Review and
approve course
completion
Supervisor ERP / LMS
Human Resources
Risk Management (Injury)
Future
Human Resources
Risk Management (Injury)
Future
EmployeeEmployeeDepartmentDepartmentHuman ResourcesHuman ResourcesVersion_1.2Version_1.2
Injury
Complete injury
report
Employee /
Supervisor ERP
Complete injury
report
Employee /
Supervisor ERP
Receive notice of
injury
HR
Generalist ERP
Receive notice of
injury
HR
Generalist ERP
Add additional
information in claim,
follow up questions
HR Generalist ERP, Manual
Add additional
information in claim,
follow up questions
HR Generalist ERP, Manual
Treatment
required?
Mark case as
completed
HR
Generalist ERP
Mark case as
completed
HR
Generalist ERP
No End
Receive care /
check up
Employee Doctor visit
Receive care /
check up
Employee Doctor visit
Update case
information
HR
Generalist ERP
Update case
information
HR
Generalist ERP
Yes
Change to duty
status?
Update employee
duty status and
eligible pay codes
HR
Generalist ERP
Update employee
duty status and
eligible pay codes
HR
Generalist ERP
Complete light /
modified duty work.
Complete time sheet
Employee ERP
Complete light /
modified duty work.
Complete time sheet
Employee ERP
Modified Duty
Notified of work
accommodations
Supervisor ERP
Notified of work
accommodations
Supervisor ERP
Light
Time sheets
complete
Supervisor /
Automatic ERP
Time sheets
complete
Supervisor /
Automatic ERP
No Worker’s Comp
Return to work
notification
Return to work
Human Resources
Risk Management (FMLA)
Future
Human Resources
Risk Management (FMLA)
Future
EmployeeEmployeeDepartmentDepartmentHuman ResourcesHuman ResourcesVersion_1.2Version_1.2
FMLA
Request FMLA, with
documentation and
leave type
Employee ERP
Request FMLA, with
documentation and
leave type
Employee ERP
Time sheet update /
Enter FMLA on time
sheet
Employee ERP
Time sheet update /
Enter FMLA on time
sheet
Employee ERP
Eligible?Yes
Approve FMLA
request, open
FMLA time code
to employee
HR
Generalist ERP
Approve FMLA
request, open
FMLA time code
to employee
HR
Generalist ERP
Receive
notification
Auto ERP
Receive
notification
Auto ERP
Deny request,
employee
notified
HR
Generalist ERP
Deny request,
employee
notified
HR
Generalist ERP
No
Receive
notification
Auto ERP
Receive
notification
Auto ERP
Able to
return?
When approved
FMLA exhausted,
notify employee
HR Generalist ERP
When approved
FMLA exhausted,
notify employee
HR Generalist ERP
Return to
WorkYes
No
Time Entry / Payroll
Scheduling
Future
Time Entry / Payroll
Scheduling
Future
FireFirePolicePoliceDepartmentsDepartmentsVersion_1.2Version_1.2
Start
Schedules were built in
Crew Sense(48/96)
FD Staff Crew Sense
Schedules were built in
Crew Sense(48/96)
FD Staff Crew Sense
Time Off Requests in Nov /
Dec for following year, or
ad hoc throughout the year
Employee Crew Sense
Time Off Requests in Nov /
Dec for following year, or
ad hoc throughout the year
Employee Crew Sense
Employee calls off
Employee Phone; Email
Employee calls off
Employee Phone; Email
Post shift to Trade
Board
Employees CrewSense
Post shift to Trade
Board
Employees CrewSense
Shift bidding (3x
per year)
Employee PACE
Shift bidding (3x
per year)
Employee PACE
Start
Employees
assigned to shifts
and apparatus
Deputy Chief Crew Sense
Employees
assigned to shifts
and apparatus
Deputy Chief Crew Sense
Scheduling assignments generally do
not change unless requested /
turnover
Trade
needed?
Review and
approve trade.
System updates
schedules.
Supervisor Crew Sense
Review and
approve trade.
System updates
schedules.
Supervisor Crew Sense
Yes Call off?Yes Below shift
min?
Push out callbacks
Supervisor CrewSense
Push out callbacks
Supervisor CrewSense
Yes
Respond and take
shift
Employee CrewSense
Respond and take
shift
Employee CrewSense
Schedule updated
Automatic CrewSense
Schedule updated
Automatic CrewSense
No
No
Acting up?
Record acting up
time
Employee CrewSense
Record acting up
time
Employee CrewSense
YesRecord time
Employee CrewSense
Record time
Employee CrewSense
Time
Entry
Time
Entry
Schedules built per
CBA (4 10s; 4 shifts)
PD Staff PACE
Schedules built per
CBA (4 10s; 4 shifts)
PD Staff PACE
Employees
assigned to shifts
PD Staff PACE
Employees
assigned to shifts
PD Staff PACE
Vacation and comp time is first
come, first serve and done year in
advance
Work internally to
find trade, notify
supervisor
Employees Email;
Manual
Work internally to
find trade, notify
supervisor
Employees Email;
Manual
Trade
needed?
Approve change
and make updates
in PACE
Supervisor PACE
Approve change
and make updates
in PACE
Supervisor PACE
Yes Call off?
No
Employee calls off
Employee Phone; Email
Employee calls off
Employee Phone; Email
Below shift
min?Yes
Hold staff over or
bring staff in early
PD Staff Manual;
PACE
Hold staff over or
bring staff in early
PD Staff Manual;
PACE
15 hour max
Schedule updated
Automatic PACE
Schedule updated
Automatic PACE
Yes
No
Acting up?
Record acting up
time
Employee PACE
Record acting up
time
Employee PACE
Yes
Record time, if
different from
schedule
Employee PACE
Record time, if
different from
schedule
Employee PACE
No
No
No
No
Eligible coworker
can pick up shift or
trade
Employee Crew Sense
Eligible coworker
can pick up shift or
trade
Employee Crew Sense
Potentially could be
done in system
Potentially could be
done in systemPotentially could be automated in PACE
Start
Schedules built in
system
Supervisor ERP
Schedules built in
system
Supervisor ERP
Post shift to trade
board
Employees ERP
Post shift to trade
board
Employees ERP
Employees
assigned to shifts
Supervisor ERP
Employees
assigned to shifts
Supervisor ERP
Trade
needed?
Review and
approve trade.
System updates
schedules.
Supervisor ERP
Review and
approve trade.
System updates
schedules.
Supervisor ERP
Yes Yes
Eligible coworker
can pick up shift or
trade
Employee ERP
Eligible coworker
can pick up shift or
trade
Employee ERP
If employee shift does not get picked up,
originating employee remains
responsible for shift
Call off leads
to staffing
shortage?
No
Receive notification
of call off /
shortage
Supervisor ERP
Receive notification
of call off /
shortage
Supervisor ERP
Push out available
shift to
unscheduled
employees
Supervisor ERP
Push out available
shift to
unscheduled
employees
Supervisor ERP
Receive notification
and pick up shift
Employee ERP
Receive notification
and pick up shift
Employee ERP
Time
Entry
Time
Entry
No
Time Entry / Payroll
Time Entry & Approval
Future
Time Entry / Payroll
Time Entry & Approval
Future
EmployeeEmployeePayrollPayrollSupervisorSupervisorVersion_1.2Version_1.2
Receive notification
to correct / of
correction
Employee ERP
Receive notification
to correct / of
correction
Employee ERP
Employees enter time on time
sheet (Salaried employees do
exception entry)
Employee ERP
Employees enter time on time
sheet (Salaried employees do
exception entry)
Employee ERP
Employee approves
their time card
Employee ERP
Employee approves
their time card
Employee ERP
Receive notification
to review and
approve time cards
Supervisor ERP
Receive notification
to review and
approve time cards
Supervisor ERP
Send back to employee to
correct. Or supervisor
can edit and approve.
Supervisor ERP
Send back to employee to
correct. Or supervisor
can edit and approve.
Supervisor ERP Yes
Review and
approve
Payroll ERP
Review and
approve
Payroll ERP
Notification of
approved time card
Automatic ERP
Notification of
approved time card
Automatic ERP
Payroll
Calculations and
Processing
End
SchedulingScheduling
Start
Employees punch in /
out on time clock
Employee ERP / Time
Entry Hardware
Employees punch in /
out on time clock
Employee ERP / Time
Entry Hardware
Time from schedule
imported to time
card
Employee ERP
Time from schedule
imported to time
card
Employee ERP
During implementation, it will be
determined if employees submit their
time via the scheduling system or ERP,
and if project codes are available in
scheduling system
Enter PTO /
Scheduled PTO
auto-populates
Employee ERP
Enter PTO /
Scheduled PTO
auto-populates
Employee ERP
Charge to specific
projects
Employee ERP
Charge to specific
projects
Employee ERP
Enter pay code
for entry (regular,
acting up, etc.)
Employee ERP
Enter pay code
for entry (regular,
acting up, etc.)
Employee ERP
System validates
based on payroll
rules
Automatic ERP
System validates
based on payroll
rules
Automatic ERP
Entered
correctly?No
Correct hours and
resubmit
Employee ERP
Correct hours and
resubmit
Employee ERP
Entry deadline
approaching?
Reminder
notification sent
to employee
Automatic ERP
Reminder
notification sent
to employee
Automatic ERP
Query to see who
has not entered
time
Payroll ERP
Query to see who
has not entered
time
Payroll ERP
Send message to
employee or time
keeper
Payroll ERP
Send message to
employee or time
keeper
Payroll ERP
OT &
Special Pay
Time Entry / Payroll
OT & Special Pays
Future
Time Entry / Payroll
OT & Special Pays
Future
PayrollPayrollEmployeeEmployeeVersion_1Version_1
Time
Entry
Employee file determines
eligibility for incentive pays
and applies to eligible
hours
Automatic ERP
Employee file determines
eligibility for incentive pays
and applies to eligible
hours
Automatic ERP
Employee makes OT /
Comp Time elections, if
applicable
Employee ERP
Employee makes OT /
Comp Time elections, if
applicable
Employee ERP
System calculates OT
when time entered
exceeds regular time
rules (daily and weekly)
Auto ERP
System calculates OT
when time entered
exceeds regular time
rules (daily and weekly)
Auto ERP
Rules configured during
implementation
OT
Position / labor group determines special
pay eligibility. System applies rules based
on pay code entered (e.g., acting) or
automatic (e.g., shift differential)
Automatic / Employee ERP
Position / labor group determines special
pay eligibility. System applies rules based
on pay code entered (e.g., acting) or
automatic (e.g., shift differential)
Automatic / Employee ERP
Special Pay
Incentive
Pay
Calcs
Time Entry / Payroll
Payroll Calculations & Processing
Future
Time Entry / Payroll
Payroll Calculations & Processing
Future
PayrollPayrollAccountingAccountingEmployeeEmployeeVersion_1.2Version_1.2
Time
Approval
Time
Approval
Calculate gross pay
based on configured
business rules
Payroll / Auto ERP
Calculate gross pay
based on configured
business rules
Payroll / Auto ERP
Run draft payroll
Auto ERP
Run draft payroll
Auto ERP
Create direct
deposit flat file,
send to bank
Payroll ERP
Create direct
deposit flat file,
send to bank
Payroll ERP
Direct deposits
issued
Auto Bank
Direct deposits
issued
Auto Bank
Run final payroll
Payroll ERP
Run final payroll
Payroll ERP
Make corrections
Payroll ERP
Make corrections
Payroll ERP
Yes
Deductions calculated
based on configured
business rules
Auto ERP
Deductions calculated
based on configured
business rules
Auto ERP
Reimbursements /
configured
allowances
Auto ERP
Reimbursements /
configured
allowances
Auto ERP
Approve?
No
Print checks
Payroll ERP / TPS
Print checks
Payroll ERP / TPS
Employee
Reimb.
Employee
Reimb.
Paystubs /
remittance added to
Employee portal
Auto ERP
Paystubs /
remittance added to
Employee portal
Auto ERP
Payroll expense
posts to GL &
Project Ledgers
Auto ERP
Payroll expense
posts to GL &
Project Ledgers
Auto ERP
Deductions
aggregated by
category / vendor
Auto ERP
Deductions
aggregated by
category / vendor
Auto ERP
Review and
approve deduction
summary
Payroll ERP
Review and
approve deduction
summary
Payroll ERP
AP
Time Entry / Payroll
Retro Pay
Future
Time Entry / Payroll
Retro Pay
Future
DepartmentsDepartmentsPayrollPayrollEmployeeEmployeeVersion_1Version_1
Requests time
change / payroll
correction
ERP
Requests time
change / payroll
correction
ERP
Review and
approve
Manager ERP
Review and
approve
Manager ERP
Run retro pay
calculation
Payroll
Manager ERP
Run retro pay
calculation
Payroll
Manager ERP
Make
adjustments
Payroll
Manager
Manual /
ERP
Make
adjustments
Payroll
Manager
Manual /
ERP
NoCalculation
Correct?
Credit / debit
issued to following
paycheck
ERP
Credit / debit
issued to following
paycheck
ERP
Yes
Journal Entry
posts
Automatic ERP
Journal Entry
posts
Automatic ERP
Payroll
Calcs
Initiate mass update (e.g.,
contract renegotiation) and
set effective date
Payroll ERP
Initiate mass update (e.g.,
contract renegotiation) and
set effective date
Payroll ERP
Start
Start
Part III: PowerPoint from Pre-Proposal Conference
C I T Y O F B O Z E M A N , M O N T A N A
Enterprise Resource Planning
(ERP) Software and
Implementation Services
Pre-Proposal Conference
March 24, 2026
T O D A Y ' S A G E N D A
1 Welcome & Purpose
2 City Overview & Context
3 Why We're Replacing the ERP
4 Implementation Goals
5 Key Challenges to Solve
6 Procurement Logistics
7 · Q&A & Next Steps The majority of our time together
01 · WELCOME & PURPOSE
Setting the Stage
Clarify Context
Help vendors understand the City's
environment, scale, and procurement
process so proposals are informed and
competitive.
Answer Questions
This is your opportunity to ask questions that
will sharpen your proposal. The majority of
this meeting is reserved for Q&A.
Scope is Set
This conference does not modify the RFP.
The scope, timeline, and requirements are
established —not up for negotiation today.
Material questions will be included in the question response addendum.
02 · CITY OVERVIEW & OPERATING CONTEXT
Scale & Complexity at a Glance
~57,000
Population Served
25
City Departments
540 FTEs
Plus ~140 Seasonal Workers
$230m
Annual Budget Across All Funds
4
Collective Bargaining Units,
accounting for ~70% of employees
Biweekly
Pay Cycle
03 · WHY THE CITY IS REPLACING ITS ERP
Strategic Drivers for Change
The City's decision to replace its ERP is driven by a forward-looking vision to
modernize operations, improve transparency, and position Bozeman for continued
growth.
Modernization of aging legacy platform
Consolidate disparate systems and reduce manual work
Improved reporting & financial transparency
Standardized processes across departments
S U C C ES S I N 5 –1 0 Y EAR S
Real-time financial visibility citywide
Integrated workflows across all departments
Self-service reporting
Audit-ready, secure data environment
Platform that scales with Bozeman's growth
04 · IMPLEMENTATION GOALS & GUIDING PRINCIPLES
How the City Will Approach This Project
Process Improvement First
This is not a lift-and-shift. The City is using this opportunity to
redesign and standardize business processes —not just
recreate the old ones.
Configuration Over Customization
The City will adopt best-practice configurations wherever
possible and looks for vendor support in advising on efficient
industry standard practices that meet City needs. Custom
development is a last resort.
Change Management Partnership
The City owns adoption and organizational change, but it will
look for vendor support with tools and training to drive buy-in
and adoption.
Clean Data Conversion
Data conversion will prioritize balances and clean master
records. Historical transaction migration will be scoped
carefully to control risk and cost.
Governance and standardization are core to the City's long-term ERP success.
05 · KEY CHALLENGES THE CITY IS ASKING VENDORS TO SOLVE
Partnering to Solve Key Challenges
Understanding the City’s key challenges and providing clear, actionable guidance will be viewed favorably.
✓Integration with Existing Systems
Support in developing efficient integrations with core systems to reduce
manual intervention and duplicate work.
✓Data Access & Reporting
Department-level self-service reporting without dependence on IT staff
for ad hoc queries, including integration with existing reporting tools.
✓
Modernizing Purchasing Practices
Implementing best-practice purchasing workflows, along with managing
the change for these new practices.
✓
Staffing Plan Development
Effectively and efficiently managing, tracking, and approving staffing
requests over a multi-year period.
✓
Capital Asset Accounting
A modern, best-practice approach to managing vertical and horizontal
infrastructure, including contributed capital.
✓
Disparate Payment Systems
Multiple disconnected payment channels requiring consolidation and
reconciliation.
Additional challenges are noted in the RFP
06 · PROCUREMENT & EVALUATION LOGISTICS
Timeline and Key Terms
RFP Released
March 14
Pre-Proposal Conf
Today
Questions Due
March 27
Responses Issued
April 7
Proposals Due
May 4
Elevation
June 16
Demos
July 14-16, 21-23, 28-30
Award
Late September
"Yes" Is Binding
A "Yes" response to a requirement commits your firm to delivering it. Do
not mark Yes unless you can fully comply.
Fixed Fee Contract
Fixed fees shall include all labor, hours, effort, and resources necessary to
complete the agreed-upon scope
Deliverables, Milestones, & Acceptance
Key work products (Deliverables) will require Bozeman review and approval
with defined acceptance criteria. Milestones drive payments and consist of
one or many Deliverables, work products, and/or events.
Questions
Ask! Do not assume! If you are unclear on a request or need more
information to accurately price this project, please ask!
Discovery
September 16-17
0 7 · Q & A & N E X T S T E P S
Your Questions.
Written Questions
Submit all follow-up questions in writing to by March 27.
Addenda Posted
All Q&A responses will be documented and posted as an
addendum in the RFP portal on April 7 .
Today’s Questions
Material questions will be included in the question
response addendum.
Thank you for your interest in partnering with the City of Bozeman.