Defining the Scope of Your ERP Project. Agree what is included, excluded and needed from other systems.
A workable ERP release needs a complete operating boundary. It must explain which business events the release will handle, where responsibility passes to another process or system, and how the business will know that the whole outcome works.
A list of functions or departments leaves too much unanswered. “Order management is in scope” does not say what happens when an order is partially shipped, changed after release, rejected by a carrier, or paid without a matching reference. Those events may cross several systems even when only one is being replaced.
The aim is the smallest coherent operating scope: a release that can perform its promised business function, including necessary exceptions and controls, without depending on undefined work outside its boundary. Finding that boundary is a design decision with consequences for cost, staffing, acceptance, and day-to-day operations.
Begin with a plain-language outcome and its population. For example: “The first release will support domestic stocked-product orders for the main distribution location, from accepted order through invoicing and the handoff of receivables to the retained finance process.”
The wording makes several boundaries visible. It specifies geography, product type, location, starting event, ending event, and an adjacent process. It still needs refinement, but people can now ask concrete questions. What counts as an accepted order? Are returns included? What happens to orders already open at transition?
Have the accountable business owner explain how the release will operate on an ordinary day and on a difficult day. The project manager records the boundary; the business owner accepts the operating consequences. Technical leads identify dependencies, while control owners identify evidence required for their responsibilities.
This discussion may show that the initial release is too large. It may also show that cutting it further would create more temporary work than the organization can manage. Smaller software scope does not automatically mean a simpler operating transition.
Draw a context diagram with the proposed release in the center and adjacent processes, systems, and external parties around it. Use arrows for meaningful business handoffs: orders, shipment instructions, confirmations, invoices, payments, changes, and errors.
For each crossing, record the sender, receiver, information transferred, timing, acceptance rule, failure response, and reconciliation owner. The level of technical detail can increase during design. The responsibility cannot remain undefined until then.
Include crossings performed by people. A daily file upload, a phone call to release a shipment, or a manually maintained reconciliation is part of the operating design. Removing an automated interface from scope does not remove the need to complete the underlying handoff.
Then follow at least one transaction backward as well as forward. A cancellation or correction can reveal dependencies that the standard flow misses. Ask who can reverse the event, how related records are updated, and how another team learns that its previous information is no longer valid.
For each major outcome, complete six connected parts:
CuriousRubik proposes this canvas as a working conversation tool. It should fit alongside the organization's existing scope and delivery records rather than create a competing specification. Its value comes from forcing inclusions, exclusions, and proof to be considered together.
A useful exclusion describes what remains in place. “Historical transactions excluded” is incomplete. Clarify which records remain accessible, where users retrieve them, how open items are handled, and who validates any retention or access obligations. Avoid making an operating gap disappear through a wording choice.
A release boundary is coherent when the business can complete its promised outcomes with known responsibilities and supportable dependencies. Test it using a small set of deliberately varied scenarios, chosen by operational consequence rather than convenience.
Include a normal transaction, a material exception, a correction, and an event that crosses the transition date. Add scenarios for high-consequence conditions in the business. The selection is a reasoning exercise; no universal number of scenarios can establish completeness for every organization.
For each scenario, ask whether every required step has an owner, whether the necessary information exists, whether handoffs are defined, and whether the result can be checked. An answer of “another team will handle that” should point to an accepted responsibility, not merely a team name.
Do not require every improvement in the first release. A manual step can be acceptable when its volume is manageable, the work is staffed, the control is understood, and its failure is detectable. The same step may be unacceptable during peak demand or where errors cannot be corrected promptly. Evaluate the actual operating conditions before accepting the workaround.
Consider a hypothetical distributor replacing the workflow for one location's stocked-product orders. The initial proposal includes order acceptance, allocation, dispatch confirmation, and invoicing. The carrier connection and the existing cash-receipt process remain outside the replacement scope.
Tracing the standard order shows two necessary crossings: dispatch information passes to the carrier, and invoice information passes to the retained finance process. The team assigns owners for transfer, acknowledgment, and reconciliation on both sides. These handoffs become delivery responsibilities even though the adjacent systems are not being replaced.
The exception walkthrough reveals a partial shipment. An order for ten units ships six today and four later. The business must decide which event permits invoicing, how the remaining quantity is represented, and how cancellation of the balance is handled. The numbers are illustrative; the example demonstrates a boundary question rather than a recommended policy.
A carrier rejection exposes another gap. If a shipment instruction is rejected after dispatch has been recorded, who detects the mismatch and resolves it? The team adds an exception queue and an operational owner to the scope. Calling the carrier system “out of scope” would not have answered that question.
The cash-receipt process remains unchanged, but the finance owner needs evidence that invoice references arrive in a form the retained process can use. The acceptance scenario follows an invoice into that process and verifies that an unmatched payment can be identified and investigated. It does not claim that the first release owns every finance activity.
The resulting boundary is more precise than the original function list. It also reveals a decision: whether the added exception work fits the current release or requires a revised approach. The sponsor can now assess that trade-off with the operating consequences visible.
Temporary arrangements need an owner, operating instructions, expected workload, control evidence, support route, and a retirement condition. Record the event that will end each arrangement and the person who will confirm it can be removed.
For example, a manual daily reconciliation might bridge two release waves. Estimate the volume the team must handle and test the procedure with representative data. Identify how missed or duplicate transfers are detected. Define what happens if the next wave is delayed and the temporary workload continues longer than planned.
Include the arrangement in training and acceptance. A process that works only because the project team performs an undocumented step is not yet ready for business ownership. The operational team must be able to recognize and resolve the expected exceptions with the support available after transition.
Review the total burden of workarounds. Each may appear manageable in isolation while their combined demand exceeds the capacity of the same small team. Scope decisions need a consolidated operating view, especially when several exclusions shift work onto shared finance, service, or data roles.
When a new request arrives, first determine what kind of request it is. It may be an omitted requirement necessary to fulfill the approved outcome, a changed business condition, a correction to an earlier assumption, or a genuinely new improvement.
This classification matters. Treating every late discovery as optional scope expansion can leave the original outcome unworkable. Treating every desirable improvement as an omission can make the boundary meaningless. Ask the requester to connect the change to a specific business event, consequence, or acceptance gap.
Assess the change across process, data, controls, interfaces, training, support, capacity, and temporary operations. A small screen change can alter approvals or reporting. A new location can add distinct calendars, responsibilities, or transition needs. Estimate the net effect, including work removed as well as work added.
The decision record should state the request, its relationship to the agreed outcome, alternatives, cost and timing consequences, affected acceptance evidence, and approving authority. If a change is deferred, name the operating arrangement that makes deferral workable. A backlog entry alone does not support the business on release day.
A signed scope document records agreement. Completion still requires evidence that the agreed outcome works across its boundary. Carry the canvas into design reviews, test planning, and operational acceptance so that its conditions remain visible.
When the scope changes, update the affected scenarios and dependencies as well as the description. Preserve the previous decision and the reason for revision. This prevents teams from testing an old promise against a newly narrowed implementation without realizing the mismatch.
For an immediate scope review, choose one important transaction and follow it from the first business event to the last accepted handoff. Include one reversal or exception. Wherever responsibility becomes vague, add an owner and required evidence. The resulting boundary may be wider or narrower than expected, but it will be a boundary the business can operate.