An ERP proposal can be affordable while the operating model required to sustain it is not. Subscription fees and implementation invoices are visible purchasing decisions. The less visible commitments are the controller who must resolve data definitions, the process owner who must approve changes, the integration engineer who must investigate failed transactions, and the business team that must retest a release while still serving customers.
A useful ownership estimate therefore answers two different questions: how much cash will this decision consume, and can the organization supply the capacity it assumes? Approving the first without testing the second creates an implementation plan that may balance financially but cannot be staffed.
For a CFO and CIO comparing ERP options, the practical recommendation is to establish a common lifecycle boundary before comparing prices. Then keep cash expenditure, internal capacity and uncertain exposure visible as separate views. Combining everything into one impressive total too early can hide the assumptions that should determine the decision.
Define the service you intend to own
Start with a business service rather than a product name. “Finance ERP for three entities” is still too vague for a useful estimate. Does the service include consolidated reporting, purchasing approvals, bank connectivity, tax interfaces, warehouse transactions, document retention, identity administration and support across time zones? Which of those capabilities must remain available during cutover? Which existing applications will continue operating?
Two bids cannot be compared fairly if one includes a tested bank interface while the other assumes an employee will upload files. The employee’s work remains part of the service even when it sits outside the software contract. Likewise, a proposal that excludes historical transactions may be reasonable, provided the business also prices and owns the archive that will answer future inquiries.
Write a short boundary statement listing included capabilities, entities, transaction volumes, operating hours, integrations and retained systems. Follow it with explicit exclusions and the owner of each excluded dependency. A blank entry should remain an unresolved estimate, rather than becoming a zero.
The US Government Accountability Office’s 2020 cost-estimating guide supports lifecycle coverage, documented assumptions, sensitivity analysis and updating estimates with actual costs. Its guidance concerns public programs and is not an ERP price benchmark. Those estimating disciplines are useful for a commercial ERP decision, but the business still needs its own scope and cost evidence. GAO Cost Estimating and Assessment Guide.
Follow cost beyond implementation
An ownership model should follow the work through selection, implementation, operation, change and eventual exit. This is a proposed planning structure, not a validated industry scoring system. The purpose is to expose omissions and assign responsibility.
During selection, include evaluation effort, process discovery, sample-data preparation and commercial review. These costs may already have been incurred by the time a purchase decision is made. Show them in the lifecycle record, but do not treat sunk expenditure as a reason to select a future option.
During implementation, include cleansing and reconciliation, migration rehearsals, interface testing, training preparation, cutover support and backfill for employees assigned to the project. “The business will provide data” is a work package requiring time, acceptance criteria and a named owner. It is not a cost estimate.
During operation, include administration, access reviews, support, integration monitoring, reporting maintenance and recovery exercises. Clarify what the vendor actually supplies. Infrastructure availability does not automatically resolve a rejected invoice, an incorrect approval route or a broken mapping to a connected application.
During change, include regression testing, adaptation to new business units, updates to connected systems and changes to controls. A configured workflow can require continuing ownership even if no custom code was written. Test environments and knowledgeable reviewers are recurring dependencies.
During exit, consider extraction, archive access, replacement integrations, parallel operation, reconciliation and the final removal of access. An organization does not need to predict its next platform precisely. It should know whether it can retrieve essential records and what work would remain if it changed providers.
Separate three views of the commitment
The cash view records amounts expected to be paid: subscriptions, implementation fees, contractors, environments, training services and incremental hires. Each entry needs a basis such as a contract term, supplier quote or explicitly labeled planning assumption. Record when payment occurs as well as how much it is.
The capacity view records work expected from existing employees. Use hours, skills and calendar windows before applying a monetary rate. A controller with 200 hours available in a quiet quarter does not necessarily have 200 hours available during year-end close. A theoretical labor value is useful for comparing alternatives, but it should not be presented as incremental cash if the employee will be paid anyway.
The uncertainty view records conditions that could change cost or feasibility. Examples include unresolved source-data quality, acquisition timing, transaction growth and an interface whose supplier has not confirmed access. Associate each uncertainty with an assumption, an owner, an investigation and a decision date. A range without a reason is only a wider guess.
These views can be reconciled in an economic appraisal, but keep their classifications intact. If a contractor replaces an employee’s project allocation, reduce the employee assumption before adding the contractor cost. If a subscription already includes a service, do not also price it as an external add-on unless the estimate describes additional work.
A worked comparison that changes the decision
Consider a hypothetical distributor evaluating two options over implementation plus three full operating years. All amounts below are invented planning figures in US dollars, not market prices, quotations or expected savings. Taxes, financing and discounting are excluded to keep the arithmetic visible; an actual investment appraisal should apply the organization’s policies consistently.
Option A has $180,000 of implementation fees and $90,000 per year of subscription and external support. Its implementation-plus-three-operating-year external cash subtotal is $450,000: $180,000 plus three times $90,000. Option B has $240,000 of implementation fees and $95,000 per year of subscription and external support, making its subtotal $525,000. Looking only at these lines makes A appear $75,000 cheaper.
The implementation team then estimates the internal work. A requires 1,200 hours initially and 700 hours in each operating year. B requires 1,500 hours initially and 350 hours in each operating year. A therefore requires 3,300 hours and B 2,550 hours. Using an explicitly illustrative fully loaded rate of $60 per hour produces capacity valuations of $198,000 and $153,000. Across implementation plus three full operating years, the combined resource estimates become $648,000 for A and $678,000 for B, before unresolved items. A’s apparent advantage narrows to $30,000.
That calculation still does not determine the winner. B requires more internal effort at the beginning, when the distributor may have the least capacity. A requires more recurring effort, which could constrain a small support team. If B’s lower recurring effort depends on a data quality assumption that has not been tested, its apparent operating advantage remains uncertain.
The next decision should fund a small validation exercise: run representative exceptions through each proposed operating model, record actual business intervention and determine which skills those interventions require. That exercise may change the cost assumptions or reveal that neither option can meet the service requirement. The value of the model is the investigation it directs, not the precision of the spreadsheet.
Estimate exceptions before applying an average
Average transaction cost can conceal the work that makes ERP ownership expensive. A straight-through purchase invoice may require little intervention. An invoice with a disputed quantity, a missing receipt and an ambiguous entity assignment can involve procurement, operations and finance.
Build estimates around a small set of recognizable transaction classes: routine, recoverable exception and specialist exception. Use observed samples where available. Record both handling time and waiting time, because labor capacity and service delay answer different questions. Avoid multiplying one unusually difficult incident across every transaction, or assuming the cleanest demonstration represents the operating workload.
For each class, ask who resolves it, where the evidence lives and how it returns to the normal process. If resolution depends on one person remembering an undocumented rule, the ownership model has a resilience problem as well as a labor cost. Documentation, cross-training or redesign might be preferable to simply buying more support hours.
This approach also prevents false savings claims. Eliminating ten minutes of work does not automatically remove ten minutes of payroll. It may release capacity for another task, reduce overtime, avoid a future hire or shorten a customer’s wait. Record the intended benefit and how management will realize it. Do not add all those outcomes together if they describe the same released time.
Test assumptions that could reverse the choice
Sensitivity analysis should focus on decisions. Ask which plausible change would make the preferred option unattractive, rather than changing every input by the same arbitrary percentage.
For a growing business, test the licensing or consumption measure that actually drives charges. For a multi-entity business, test the work required to onboard another company. For an integration-heavy operation, test a supplier interface change and the effort to recover failed transactions. Ask procurement to confirm the applicable commercial mechanism rather than relying on a salesperson’s informal summary.
Separate the base case from coherent scenarios. A delayed rollout may increase parallel-operation cost and postpone benefits simultaneously. Treating those effects as unrelated can understate the consequence. Conversely, stacking every worst case into one scenario can produce a number that is too pessimistic to guide action. Explain the conditions under which each scenario would occur.
Use contingency for uncertainty that can be described, and retain a process for genuinely new scope. A blanket reserve should not conceal missing discovery. If a major data source has never been inspected, the immediate action is to inspect it and narrow the estimate.
Make the model an operating responsibility
Before signing, ask the implementation partner and internal owners to walk through the same service boundary. Resolve overlaps and gaps. Record who owns each activity after the project team leaves, which costs are contractual, which are estimated and which remain unpriced.
After approval, update the model at meaningful changes: completion of a migration rehearsal, confirmation of an interface design, onboarding of another entity or a revised support arrangement. Compare actual effort with the assumption and investigate differences. A variance is useful when it leads to a better forecast or a process change; it is less useful as a retrospective explanation of why an obsolete budget was missed.
The CFO should own the financial appraisal, while operational and technical owners remain accountable for their assumptions. A central spreadsheet cannot replace that distributed knowledge. UK government guidance on defining technology user needs similarly includes the skills needed to deliver, use and manage technology and the needs of support teams. These are practical questions for private businesses too, rather than requirements imposed on them by that guidance. Define user needs.
An ERP ownership decision is ready when leaders can explain the service they are buying, the work they will retain, the assumptions that could change the answer and the capacity they have committed. The lowest quote may still be the best choice. The difference is that it wins a complete comparison rather than an incomplete one.
