Write an ERP scope your business can actually accept
Review an ERP statement of work through deliverables, dependencies and acceptance evidence. Separate defects, new requests and unresolved business decisions.
An ERP statement of work should let a business owner recognize what will be delivered, what evidence will show it works and what remains outside the engagement. Application names and a target launch date are not enough to make that decision.
Use the following as an operational review worksheet for a proposed scope. It is not contract language. Commercial commitments and legal terms still belong in the parties' reviewed agreement.
Start with one result the business can accept
Compare these two descriptions:
“Implement Sales, Inventory and Accounting.”
“For the agreed order types, the order-entry team records accepted demand, the warehouse records the relevant movement, and billing prepares an invoice that can be traced to the accepted order and delivery evidence.”
The second description is an illustrative scope statement, not a promise about a particular configuration. It gives the team a path to inspect. It still needs boundaries: which order types, locations, users, exceptions, source records and accounting rules?
Write those boundaries before dividing the project into tasks. Otherwise the delivery team and buyer can complete different interpretations of the same sentence.
Describe deliverables as records someone can review
Here is an example scope table for a fictional first order-to-invoice release. Replace each entry with the actual agreement; none of these rows defines DATUM's commercial terms.
| Deliverable | Included boundary to name | Acceptance evidence | Boundary to resolve explicitly |
|---|---|---|---|
| Agreed workflow | Named order types, roles and exceptions | Process owner reviews normal and exception scenarios | Other business units and order types |
| Configured system | Exact edition, version, hosting and applications | Test results using each role's permissions | Custom code and third-party modules |
| Migrated data | Named objects, source systems and cutoff | Counts, values and relationships reconcile | History, attachments and source cleanup |
| Connection to another system | Records, fields, direction and triggers | Normal, failed and duplicate-transfer tests | Other interfaces and future API changes |
| User preparation | Roles, tasks, materials and practice setting | Users perform agreed tasks and handle an exception | Ongoing onboarding for future hires |
| Release handoff | Cutover steps, support contacts and open issues | Authorized readiness decision and accessible records | Continuing improvements after the agreed period |
An exclusion should say where the work goes. “Historical attachments remain in the approved archive and can be retrieved by the named owner” is more useful than “history excluded,” if that is the actual agreed approach. Do not claim an archive is usable until retrieval and access are checked.
Separate product access from implementation work
For an Odoo 19 Enterprise project, record the subscription and hosting choices alongside the service scope. Odoo's pricing information distinguishes implementation services and custom-code maintenance from its software subscription. A software purchase and a delivery agreement therefore need to be read together. Odoo pricing.
The technical design must also fit the hosting choice. Odoo Online does not allow custom Python server code, while Odoo 19 documents importable XML/data modules as a separate approach. State which type of extension the scope requires and verify its deployment conditions before approving dependent development. Odoo 19 importable modules.
The scope should name who provides accounts, source exports, interface access and business decisions. Give each dependency an owner and a needed-by point. “Client to provide data” is too broad if nobody has established that the current system can export the required relationships.
Write acceptance so a different person could run it
For each critical scenario, record the starting data, user role, action, expected result and evidence to save. Include an exception as well as the normal path.
For example, a fictional acceptance test could say:
- An order-entry user opens the approved sample order.
- The user proposes a quantity change that requires review under the agreed business rule.
- An unauthorized user cannot complete the approval.
- The authorized reviewer approves the change.
- Downstream records show the agreed result without losing the original reference.
This is a proposed test, not a claim that the sequence works automatically in every ERP. The implementation must prove the chosen behavior. Define what happens if the test fails, who reviews the correction and which related tests must be repeated.
Avoid an acceptance rule based only on elapsed time or silence if the business expects an active operational check. The commercial meaning of acceptance should be resolved in the agreement; this worksheet helps specify the observable result.
Make scope changes distinguishable from defects
During delivery, compare a request with the agreed behavior before estimating more work. Keep the comparison visible.
If the agreed mapping sends a product to the wrong warehouse, that is a failure against the agreed result to investigate. If the buyer adds a previously excluded warehouse, that is a scope change to evaluate. If the original rule never says which warehouse should receive the product, the issue is an unresolved decision. Do not hide the third case by automatically calling everything a defect or a change.
A change record should identify the requested outcome, reason, affected deliverables, cost and timing effect, test changes and the person authorized to decide. Work should not become accepted scope merely because it appeared in a meeting note.
Before approving a statement of work, select one deliverable and follow it through the table, its dependencies and its acceptance test. If a reviewer cannot tell what evidence would close it, rewrite that part. The job-tracing guide can supply a concrete starting example for the discussion.