Key Takeaways
- Most phase-one ERP implementation scope decisions include processes the project team has quietly agreed to leave in spreadsheets, and those decisions rarely appear anywhere in the approved business case.
- Complex multi-element revenue allocation, event prepayments, and budget variance analysis are the processes finance teams most often defer, usually for defensible reasons that still carry a real cost.
- A phased ERP implementation holds up under executive scrutiny only when each deferred process carries a named owner, a documented workaround, and an estimated annual cost to carry it.
- Costing every exclusion protects the ERP business case from promising automation benefits that the phase-one configuration was never designed to deliver.
Requirements sessions produce two lists. One is written down and becomes the configuration backlog. The other forms in the room, out loud, and never reaches the project charter: the processes everyone has quietly agreed will stay in spreadsheets for now.
That second list is not a failure of rigor. Deferring a process is frequently the correct call. Today, we are discussing how to turn those deliberate exclusions into explicit, costed decisions instead of unspoken assumptions.
Contemplating litigation?
We have multiple software expert witnesses available for provision of reports, depositions, and testimonies.
What a Deliberate Scope Exclusion Actually Is
A deliberate scope exclusion is a process the organization has evaluated, understood, and chosen not to automate in phase one. It is not the same thing as a shadow spreadsheet, which is a workaround that appears after go-live because a requirement was missed during design. One is chosen. The other is inherited.
That distinction matters. A chosen exclusion can be governed, budgeted, and scheduled for a later phase. An inherited one surfaces during hypercare as a surprise, usually when the finance team is least able to absorb it.
Panorama's guidance on gathering ERP requirements without legacy bias addresses the accidental version of this problem. The exclusions here are the opposite case: chosen on purpose, in the open, and worth pricing.
Why Finance Teams Choose to Keep Certain Processes in Spreadsheets
By the second or third requirements session, most finance teams can name the processes they intend to keep outside the system. The pattern is consistent across industries and usually includes:
- Complex multi-element revenue allocation: a single contract has to be split across products, services, and support periods.
- Event and customer prepayments: cash arrives long before the obligation is satisfied.
- Budget variance analysis and reforecasting: the working model changes shape every quarter.
- Grant and statutory reporting: the output serves one external audience and one deadline.
The reasoning behind each deferral is usually sound. Configuration effort exceeds the year-one benefit, the process is still changing, standard functionality would require customization the organization does not want to carry through upgrades, or the team that owns the process is small and already efficient in the tool it uses.
Vertical context shapes the list. Manufacturing software systems handle standard costing and variance capture well, yet the analysis layer a plant controller presents to leadership often remains a workbook. Selection teams that spend months determining the best ERP for manufacturing sometimes spend a single afternoon deciding which finance processes will not be part of phase one.
For example, a professional services firm with a handful of contracts requiring multi-element allocation may find that configuring the revenue module costs more in consulting hours and testing cycles than the finance team spends maintaining the allocation workbook each quarter.
What an Uncosted Exclusion Costs You
An exclusion that is never written down does not stay neutral. It quietly changes four things:
- The business case: benefit models assume automation, so the saving never appears while the number stays in the approved case.
- Key-person risk: the deferred process now depends on one analyst and one file.
- Reconciliation and audit effort: two sources of truth have to be tied together every period.
- The phase-two roadmap: funding rarely materializes once leadership believes the benefit was already delivered.
Some of the most costly ERP failures are argued on exactly this point. Benefit claims that were never traceable to a documented scope become the central question in a dispute, and a computer software expert witness is asked to reconstruct what the parties actually agreed to deliver.
Expert Insight
Our ERP project recovery consultants have found that most benefit shortfalls are not caused by software that failed to work. They are caused by a business case that promised outcomes the approved scope never covered. When an executive committee asks why the close cycle did not shorten, the answer is frequently sitting in a spreadsheet that everyone in the requirements sessions had agreed to keep.
Practical Steps to Cost a Phase-One Scope Exclusion
Costing an exclusion takes roughly an hour per process. What matters is completing all four steps before scope is signed.
1. Name the Process and Its Owner
Write the process down in the language the business uses, not the module name it would have lived in, and assign a named owner accountable for running it manually. An experienced ERP consultant presses for this during requirements rather than after go-live, because an unowned process is the one that fails at the first month-end close.
2. Document the Workaround While the Decision Is Fresh
Capture the mechanics, including which file, which inputs, which reports feed it, who reviews it, and how the result returns to the general ledger. An ERP implementation consultant can turn this into a short procedure document that survives turnover in the finance team, which is where undocumented workarounds usually break.
3. Estimate the Annual Carrying Cost
Multiply the hours the process consumes each period by a loaded labor rate, then add reconciliation time, audit support, and the cost of correcting errors the system would have prevented. Present the figure annually. Twelve hours a month is not a rounding error at the executive level.
4. Adjust the Business Case and Set a Phase-Two Trigger
Remove the automation benefit that the exclusion makes unachievable, and state the condition that will bring the process into scope later, whether that is a transaction volume, a contract count, an audit finding, or a specific release date. A change to the revenue recognition standard can also serve as that trigger for allocation processes.
Learn More About ERP Implementation Scope
Every phase-one scope is a set of choices about what will not be automated yet. Organizations that write those choices down and price them arrive at go-live with a credible number. Those that leave them unspoken arrive with a benefit shortfall that is difficult to explain and harder to fund a second time.
Panorama's ERP consulting services can help you define, document, and cost a phase-one scope that your executive committee will still stand behind two years after go-live. Contact us below to learn more.
FAQs About ERP Implementation Scope
What belongs in a phase-one ERP implementation scope?
Phase one should cover the transactional core the business cannot run without: general ledger, order-to-cash, procure-to-pay, and the reporting that depends on them. Specialized processes with low volume, high complexity, or unsettled requirements are reasonable candidates to defer, provided the deferral is documented and costed.
How do we put a cost on a process we are leaving out of ERP scope?
Estimate the hours the manual process consumes each period, apply a loaded labor rate, and add reconciliation, audit support, and error-correction effort. Then identify any benefit in the business case that assumed automation of that process and remove it. The result is a defensible annual carrying cost leadership can weigh against configuration effort.
Why involve an independent ERP consultant in scope decisions?
An advisor with no revenue tied to license volume or configuration hours can recommend deferring a process without commercial consequence. That neutrality matters most where scope is set, because excluding a process is the decision where implementation cost and business case credibility trade directly against each other.
Does a phased ERP implementation weaken the business case?
Not when the phasing is explicit. A phased ERP implementation with documented exclusions and adjusted benefit figures is more credible than a single-phase case built on optimistic automation assumptions. Problems arise when the schedule is phased but the benefit model is not, which leaves leadership expecting full-scope results from a partial-scope deployment.
When does an undocumented scope exclusion cause a failed ERP project?
An exclusion becomes a project failure when nobody documented it and the business case still counts its benefits. The system performs exactly as designed, the promised savings never appear, and the project is judged against a standard it was never scoped to meet. Written, costed exclusions prevent that gap from forming.
