What Should Be Included in Your ERP Implementation? Defining the Scope

⚡ Quick Summary (30-Second Read)

• The Core Takeaway: Choosing an ERP is only step one; defining what you are implementing is what prevents failure. A clear scope sets explicit boundaries for processes, data, and integrations before technical setup begins.
• Key Scope Rules:
  • Processes Over Modules: Scoping isn’t picking software apps; it’s defining end-to-end workflows (e.g., order-to-cash).
  • Document Exclusions: Clearly state what is out of Phase 1 to prevent unintentional scope creep.
  • Categorize Requirements: Group needs into Must have, Important, Nice to have, and Later.
  • Question Legacy Habits: Don’t build custom features just to mimic old software limitations—simplifying processes usually beats custom code.
• The Bottom Line: Establish a clear initial operational scope, launch successfully, and layer in complex automation or extra modules in later phases.

---

Introduction

Choosing an ERP system is an important decision, but it is only the beginning. Once a company selects a platform and starts planning, another critical question appears:

What exactly are we going to implement?

This sounds simple, but it becomes surprisingly complex. A business may want to improve sales, purchasing, inventory, accounting, manufacturing, customer management, and reporting all at once. Employees have their own daily requests, managers have high-level priorities, and legacy software must often continue running alongside the new platform.

Without a clear scope, an implementation gradually expands beyond its original plan. The project takes longer, costs more, increases technical complexity, and creates unnecessary disruption. Defining implementation boundaries before configuration and development start is essential.

What Does ERP Implementation Scope Mean?

The scope defines what the ERP project will and will not cover. It describes the business processes, departments, physical locations, data, integrations, reports, and customisations included in the release.

Consider a wholesale business planning its initial deployment. Its Phase 1 scope might look like this:

Area	Phase 1 Scope
Sales	Included (Quotes, orders, basic customer records)
Purchasing	Included (PO tracking, supplier records, reordering)
Inventory	Included (Multi-warehouse tracking for 3 sites)
E-Commerce	Included (Webstore order sync)
Reporting	Included (Basic sales, inventory, & purchasing)
Accounting	Excluded (Kept in legacy software for Phase 1)
Manufacturing	Excluded (Not applicable for initial rollout)

Stating that a company is “implementing an ERP” doesn’t explain much on its own. Two businesses can implement the exact same platform while running completely different projects based on their chosen scope.

Why Defining the Scope Is Critical

An ERP system can support hundreds of business activities, but that doesn’t mean you should enable them all at once. Without a documented scope, new requests surface continuously throughout development:

• “While we are setting up orders, can we add this custom report?”
• “Can we integrate this secondary legacy tool?”
• “Can we include our extra warehouse location ahead of schedule?”

Individually, these requests sound reasonable. Together, they trigger scope creep, causing budget overruns and missed deadlines.

1. Initial Baseline: Clear, documented Phase 1 requirements.
2. Unvetted Requests: Feature additions introduced mid-project without evaluation.
3. Project Impact: Severe scope creep, schedule delays, and budget overruns.

A clear scope creates a boundary that helps everyone understand:

• What the project will deliver at go-live
• What is deliberately excluded
• What must be completed first versus postponed
• When additional work requires extra budget or timeline adjustments

The goal isn’t to prevent business changes entirely, but to make adjustments consciously rather than letting the project expand out of control.

Start with Business Processes, Not ERP Modules

A common mistake is defining scope simply by listing ERP module names—for example: “We need Sales, Inventory, Purchasing, and Accounting.”

Modules are functional categories; your business operates on processes. Instead of asking which software modules you need, ask: “Which business processes do we want the ERP to manage?”

Take a standard wholesale workflow:

• 1. Order Intake: Customer places order -> Sales order created.
• 2. Verification: Stock levels checked across warehouses.
• 3. Fulfillment: Warehouse prepares, packs, and dispatches goods.
• 4. Settlement: Customer invoice issued & payment recorded.

Whether you use Odoo or another platform, understanding the business process first ensures system configuration serves real operational needs.

Business Processes to Review by Department

When building your scope, review your company’s core operational areas:

Sales

• Customer enquiries, formal quotations, and sales orders
• Pricing rules, discount logic, and customer-specific price lists
• Delivery scheduling and customer invoicing

Purchasing

• Supplier record management and purchase requests
• Requests for Quotations (RFQs) and Purchase Orders (POs)
• Supplier price agreements, goods receipt logging, and vendor invoice matching

Inventory

• Multi-warehouse management and bin/location tracking
• Internal stock transfers, adjustments, and cycle counts
• Reorder rules and automated replenishment points

Finance & Accounting

• Invoicing, customer payments, and employee expense tracking
• General ledger, financial reporting, and cash flow tracking

Customer Management (CRM)

• Lead tracking, pipeline opportunities, and communication logs
• Sales activity management and follow-up schedules

Manufacturing

• Bills of Materials (BOMs), manufacturing orders, and work orders
• Production scheduling and quality control steps

Scoping requires picking the specific steps your business needs today rather than activating standard feature lists blindly.

Define What Is Included — and What Is Not

Documenting what is outside the project scope is just as vital as listing what is included.

If management decides to implement Odoo for Sales, Purchasing, and Inventory while leaving financial accounting in an existing system during Phase 1, that exclusion must be recorded:

Area	Status	Scope Boundary
Sales	Included	Full quote-to-order workflow
Purchasing	Included	PO creation & supplier tracking
Inventory	Included	3 warehouses included
CRM	Included	Basic contact master data
Accounting	Excluded	Legacy accounting tool retained
Manufacturing	Excluded	Out of scope

Documenting exclusions creates alignment across management, department heads, and implementation partners, preventing confusion during deployment.

Categorize Requirements by Priority

Not every internal request is equally urgent. Separate requirements into practical priority tiers:

• Must Have: Core items required for basic daily operation (e.g., verifying multi-warehouse stock before confirming an order).
• Important: Features providing high value where temporary workarounds exist (e.g., automated alerts for overdue quote approvals).
• Nice to Have: Helpful features that add convenience but aren’t mandatory for initial launch (e.g., custom rep performance dashboards).
• Later: Useful capabilities reserved for future deployment phases (e.g., advanced automated replenishment).

This classification keeps initial deployment focused on core business needs.

Structure a Phased Implementation

Implementing everything at once adds unnecessary risk. A phased roadmap yields faster value and lets employees adapt comfortably:

Phase 1 — Core Operations

Focus on essential daily workflows: Sales, Purchasing, Inventory, basic reporting, and critical integrations.

Phase 2 — Additional Processes

Layer in expanded capabilities once staff are comfortable: CRM pipelines, automated vendor replenishment, deeper reporting, and secondary integrations.

Phase 3 — Optimisation

Refine operations with advanced process automation, custom executive dashboards, and specialized workflow tweaks based on real usage data.

A Realistic Example

Consider a wholesale electrical distributor with 20 employees, 3 warehouses, an online webstore, 15 main suppliers, and an existing accounting system.

Rather than setting a vague goal like “Replace all software with Odoo,” the team establishes a clear Phase 1 scope:

Scope Type	Defined Operations
Included	Quotes/orders in Odoo; stock tracking for 3 warehouses; POs to suppliers; webstore order sync; central customer records; basic operational reports.
Excluded	Legacy accounting system retained; advanced barcode scanning postponed; historical logs archived in old database.

This gives the project clear, achievable deliverables for its first release.

Customisation vs. Standard Configuration

Identifying potential custom code needs early is crucial, but building custom features shouldn’t be your first reaction.

When a requirement emerges (e.g., specialized sales rep pricing rules), ask: “Does the business genuinely need a custom-coded solution?”

1. Can an existing standard feature support the workflow via configuration?
2. Can the underlying business process be simplified to match standard system logic?
3. Is custom development strictly required for competitive advantage or unique legal logic?

Modularity in systems like Odoo offers vast out-of-the-box settings. Adding custom code simply to preserve old software habits increases project complexity, cost, and long-term upgrade maintenance.

Evaluate Existing Software and Integrations

An ERP project rarely starts in a vacuum. Map your existing software environment early:

• E-commerce webstores
• Legacy accounting platforms
• Payment processors or shipping gateways
• Specialized CRM tools, payroll software, or BI tools

Decide which applications the ERP will replace and which will continue operating alongside it. If a legacy platform remains active, building and testing the system integration must be explicitly included in your project scope.

Include Data Migration and Reporting in the Scope

Data Migration Strategy

Migrating decades of legacy records is costly and time-consuming. Decide early:

• Which master records are required on Day 1 (active customers, current vendors, product catalogs, opening stock balances)?
• What historical transaction data can stay in read-only legacy archives?
• Who is responsible for auditing and cleaning data before import?

Reporting Needs

Document key decision-making reports during initial scoping rather than near launch. Ask managers: “What critical information do you need to run the business that you cannot easily access today?”

Focusing on high-value business insights keeps reporting scope practical and manageable.

Avoid Recreating Legacy Software Habits

A major risk during scoping is copying old software habits: “Our old system worked this way, so the new ERP must work the same way.”

Legacy processes often exist simply because old software had technical limitations. An ERP project is an opportunity to streamline operations rather than digitizing old inefficiencies. If native ERP replenishment can replace manual Excel calculations, adopt the native workflow.

Who Should Define the Scope?

Defining scope requires collaboration. Management provides strategic direction, but frontline staff understand operational edge cases:

• Sales staff spot customer ordering friction.
• Warehouse workers catch physical handling and dispatch details.
• Purchasing teams understand vendor lead-time realities.
• Finance teams highlight reconciliation rules.

Involving representatives across departments uncovers hidden requirements early while building cross-team buy-in.

Common Scope Pitfalls to Avoid

• Trying to Implement Everything at Once: Overloading Phase 1 delays go-live.
• Scoping by Module Names Alone: Relying on generic terms like “Inventory” instead of mapping actual workflow steps.
• Ignoring Existing Systems: Discovering unbudgeted integration needs late in development.
• Treating Every Feature as Essential: Failing to prioritize leads to bloated project timelines.
• Forgetting Documented Exclusions: Leaving out-of-scope boundaries vague causes scope creep.
• Promising Features Before Scoping: Specifying technical fixes before understanding the business problem.

A Simple Scope Documentation Format

Your scope doesn’t require a 100-page document. A clean, 2-column format works cleanly on all screen sizes:

Requirement & Phase	Scope Details
Sales Orders (Phase 1)	Must have; standard native workflow
Multi-Warehouse (Phase 1)	Must have; 3 sites configured
Purchasing (Phase 1)	Must have; PO creation & receiving
Webstore Sync (Phase 1)	Important; REST API order import
Accounting (Phase 2)	Later; legacy system retained initially
Core Reporting (Phase 1)	Important; sales margin & stock levels
Min/Max Automation (Phase 2)	Nice to have; evaluate post-launch

Conclusion

The project scope isn’t written in stone—business needs evolve, and new details emerge during development. However, having a formal baseline ensures that any new request is evaluated for budget, timeline, and operational impact before work begins.

Once your implementation scope is locked, the project moves seamlessly to the next stage: system configuration—adapting standard features to support your defined business processes efficiently.