Fit-gap analysis: documenting finance requirements before an ERP solicitation

Reference article · 5 min read

An ERP replacement usually begins to fail long before award. It fails when the solicitation describes a generic finance system instead of the work the agency actually performs, and when nobody has separated the practices the agency is required to keep from the practices it has simply grown used to. Fit-gap analysis closes that distance. It compares how work is done today against how a modern system would do it, records each difference, and produces a requirements set where every line traces to a real process and a stated reason.

The shortcut most agencies are offered is a requirements matrix borrowed from a neighboring jurisdiction or from a vendor's sample. Borrowed requirements carry the other agency's chart of accounts, bargaining agreements, rate structure, and ordinances. They read well on paper and fall apart during configuration, when the team finds that half of them do not apply and the ones that mattered were never written down.

Inventory the processes before you evaluate anything

List the finance processes the agency performs, by module: accounts payable, purchasing, general ledger and close, budget development and amendment, payroll and time entry, cash receipting, utility billing, grants, fixed assets, and project accounting. For each, capture a short factual record:

• Trigger and outcome. What starts the process and what it produces, in the words staff use.
• Actors and handoffs. Who touches it, in which department, and where it waits.
• Systems and artifacts. Every system of record, spreadsheet, shared drive, paper form, and email approval involved.
• Controls. Approval thresholds, segregation of duties, and anything the external auditor tests.
• Authority. The statute, regulation, grant condition, policy, ordinance, or bargaining agreement that shapes the step, if one exists.
• Known friction. Rework, manual re-keying, late closes, and the workarounds staff have built.

Give workarounds their own column. Shadow spreadsheets and side databases are the clearest evidence of a gap in the current system, and the strongest candidates for practices not worth rebuilding.

Bring the people who actually do the work

Directors describe policy. They usually cannot describe the exception handling that consumes the month. Staff the sessions with the technician who codes invoices, the payroll specialist who handles retroactive pay and special overtime rules, the budget analyst who assembles amendments, and the utility billing clerk who handles final bills, deposits, payment arrangements, and adjustments. Add the finance officer, an IT representative who knows the integrations, and an operating department that submits requisitions and time.

Utility billing usually diverges most from a standard package, because rates, proration, and delinquency handling are set locally. Give it dedicated sessions.

Run the sessions with a fixed structure

1. Walk the current process step by step, with the responsible staff narrating.
2. Compare it against a reference process, either a demonstrated system flow or a documented leading practice for that function.
3. Record each difference as a gap, described in one sentence.
4. Ask why the difference exists, until the answer is a citation, a policy, an auditor expectation, or an admission that this is just how it has been done.
5. Log an owner and a decision date for anything unresolved.

Keep a facilitator and a separate scribe. Do not let the group draft requirement language during the session. Capture facts, then write requirements afterward, when the authority for each can be checked.

Classify every gap so the requirement can be defended

The value of the exercise is in the sorting. Assign each gap one category:

• Statutory or regulatory. Driven by state law, a state uniform accounting or budgeting manual, federal grant administration rules, payroll tax and wage-hour obligations, or records retention. Confirm each with the official source or your counsel, since specifics change.
• Audit or governing body. Required by external audit testing, an adopted policy, or an ordinance the council or board could amend.
• Operational necessity. Not legally required, but the agency cannot deliver service without it.
• Local habit. A practice that exists because a prior system could not do something else.
• Missing capability. Something the agency should be doing and cannot do today.

Statutory items become mandatory requirements. Habits become process change decisions, recorded with the name of the person who agreed to retire them. That record keeps a department from reintroducing the workaround during design, and gives staff a defensible way to say a practice should not be carried forward.

Turn the output into a requirements matrix

Write one testable requirement per line. Give each a stable identifier, a module, a plain statement of what the system must do, its category, the authority behind it, a priority, and the evidence that would demonstrate compliance. Avoid vendor terminology and unmeasurable adjectives. "The system shall support user-friendly workflow" cannot be evaluated. "The system shall route a requisition above an adopted threshold to a second approver and retain the approval record" can be.

What to ask vendors, and what to put in the contract

• Ask which requirements are met by configuration, which by a supported extension, and which require custom development, and what happens to each at upgrade.
• Script demonstrations from your own matrix, using your own data, rate structure, and pay rules, rather than accepting a standard demo.
• Ask which statutory and grant reports ship with the product and which the agency must build.
• Require the matrix as a contract exhibit, with acceptance criteria tied to requirement identifiers.
• Require a change control process for gaps found during design, and define who pays for what.
• Require configuration documentation and data dictionaries as deliverables.

How to start

Pick two processes with known pain, run the sessions, and write those requirements first. Then schedule the rest, far enough ahead of solicitation drafting to resolve the gaps that turn out to be policy decisions rather than software questions.

Frequently asked questions