Odoo ERP
Connect your operations around a clearer way of working
When sales, purchasing, stock and finance depend on separate spreadsheets, the same information gets entered repeatedly and decisions wait for reconciliation. An Odoo project starts by deciding how those teams should work together, then configuring the system around the agreed process.
Discuss your projectA shared delivery plan
From a working process to a working Odoo system
We propose six collaborative stages, adapted to the agreed applications and business priorities. Each stage leaves something your team can review. The proposal establishes which activities are included, who makes decisions and how changes are handled. Data preparation and configuration can progress together where their dependencies allow.
We agree the stages, outputs and responsibilities in your project scope. Select a stage to explore the work and decisions.
A worked example · illustrative
One order. A connected record trail.
Illustrative distributor workflow: follow a partial delivery through the records instead of checking each application in isolation.
- QuotationItems, quantities and approved terms→
- Sales orderConfirmed commitment and fulfilment plan→
- DeliveryDelivered items and remaining quantities→
- Invoice & reviewAgreed billing basis and reconciled records→
Trace the return to the delivery, the stock movement and any required credit. The finance owner confirms the applicable billing rules.
From scope to operation
The work at each stage
Open each stage to see the work, your role, the deliverables and the check before moving forward. Feedback can return a decision to an earlier stage.
Understand the operational journey
Follow one representative transaction through the people, records and exceptions involved.
What Lava does
Map the current workflow, identify repeated entry and document where responsibilities or records become unclear.
Your team provides or approves
Bring sample transactions and nominate process owners who can explain the normal work and exceptions.
Stage outputs
- Current workflow and exception map
- Named decisions and responsible people
Ready to move forward when…
Process owners confirm that the map represents the work they need to improve.
Review loop Revisit discovery when an omitted department or exception changes the intended workflow.
Choose the first release
Agree a complete initial workflow and the Odoo approach it requires.
What Lava does
Demonstrate standard behaviour, then assess settings, Studio customization and custom modules separately, checking subscription, hosting and maintenance implications.
Your team provides or approves
Prioritise requirements, approve deferred work and resolve finance or localisation questions with your responsible advisers.
Stage outputs
- First-release scope and exclusions
- Fit assessment and decision log
Ready to move forward when…
Release dependencies and deployment eligibility are confirmed; unresolved requirements are deferred or resolved before dependent work begins.
Review loop Return to the workflow when a requested change has no clear business justification.
Configure and demonstrate
Make the agreed workflow visible in a suitable test environment.
What Lava does
Configure selected applications, roles, approvals and reports; demonstrate representative transactions and capture review feedback.
Your team provides or approves
Review the demonstrations with actual users and decide how identified process differences should be resolved.
Stage outputs
- Reviewable configured workflow
- Configuration and permissions record
Ready to move forward when…
Users can follow the agreed scenario and distinguish completed work from remaining gaps.
Review loop Revisit scope when a gap needs additional development or a different hosting choice.
Rehearse the data move
Prove that selected source data becomes usable, connected records in Odoo.
What Lava does
Prepare field mapping and trial imports, then check duplicates, relationships and agreed reconciliation totals.
Your team provides or approves
Clean and approve source records, resolve ambiguities and identify the data that will remain archived.
Stage outputs
- Migration mapping and trial results
- Reconciliation and exception record
Ready to move forward when…
Data owners approve the trial results; a successful file import alone does not establish accuracy.
Review loop Return to preparation when record quality or opening balances prevent reliable reconciliation.
Test daily work and exceptions
Check the system with the people who will depend on it.
What Lava does
Coordinate acceptance scenarios and a transition rehearsal, covering role boundaries, corrections, returns and integration failures where relevant.
Your team provides or approves
Run the business scenarios, review reports and approve resolved issues or explicitly accepted limitations.
Stage outputs
- Acceptance results and issue decisions
- User guidance and transition readiness plan
Ready to move forward when…
Required scenarios pass and the business owner confirms readiness for the planned transition.
Review loop Return to configuration or migration when a failed scenario exposes an underlying problem.
Move into operation
Carry out the approved transition and hand over practical administration.
What Lava does
Follow the approved cutover, check priority transactions and any agreed data reconciliation; provide the scoped administration and support handover.
Your team provides or approves
Approve the launch decision, coordinate affected teams and nominate the ongoing system administrator.
Stage outputs
- Cutover record and operational checks
- Administration and support handover
Ready to move forward when…
Agreed launch checks pass and nominated owners can complete the agreed administration tasks.
Review loop Use the agreed recovery decision if critical checks fail; revisit affected work before proceeding.
Start with the operational problem
A useful starting point is a specific workflow: a quotation becoming an order, a purchase replenishing stock, or an invoice reaching the right person for approval. We examine the handovers, exceptions and records involved before deciding which applications belong in the first release.
This approach suits organisations that need shared records and clearer responsibility across departments. It also helps establish whether standard Odoo behaviour is sufficient, whether a process should change, or whether a justified extension is needed. Recreating every existing spreadsheet inside a new system can preserve the problems the project is meant to solve.
What your implementation can cover
The proposal defines the applications, workflows and responsibilities included. Depending on those decisions, the work can cover:
- Process mapping and a fit assessment, with a prioritised first release and a record of gaps requiring a business decision.
- Configuration of agreed applications, company settings, user roles, approval steps and essential operational reports.
- Data preparation and migration rehearsals for selected records, with field mapping, relationship checks and reconciliation against approved source totals.
- Agreed integrations or extensions, including their authentication, failure handling and ongoing maintenance responsibilities.
- Role-based user testing, training materials and a cutover plan with named decision makers, acceptance criteria and handover tasks.
Make the important choices before configuration
| Decision | What to weigh |
|---|---|
| Standard configuration or extension | An extension may solve a real gap, but also creates testing and upgrade work. Validate the need against standard behaviour first. |
| One release or phased rollout | A phased launch can reduce the initial scope; dependencies between departments still need a workable end-to-end process. |
| Plan and hosting | Confirm licensing, Studio or custom-module needs, API eligibility and hosting together. Subscription and implementation costs are separate decisions. |
Prepare the data, people and handover
Your team provides process owners, representative transactions, existing data exports and a list of approval and reporting requirements. A business owner must resolve conflicting preferences and approve the future process. Accounting and localisation requirements should be confirmed with your responsible finance advisers.
Before launch, users test normal work and exceptions in an agreed environment. Migration checks should cover duplicates, missing relationships and opening balances where relevant; importing a file successfully is not the same as proving its accuracy. Handover identifies the system administrator, access ownership, configuration documentation and the support arrangements agreed for after launch.
Questions before starting
Can we start with only a few applications?
Yes, a focused first phase can be defined around a complete business workflow. The discovery work checks what that workflow depends on, so a smaller launch does not leave essential handovers unresolved.
Can existing data be moved into Odoo?
Selected data can be assessed for migration. The effort depends on its quality, structure and history. Agree what to retain, clean and archive, then rehearse the import and have your data owners approve the results.
What determines the project cost and support needs?
Applications, process complexity, data condition, integrations, hosting and training affect the scope. The proposal should distinguish implementation from subscriptions and ongoing support, and state who handles updates and future changes.
Handover & ongoing care
After launch: keep ownership clear
Any ongoing support is defined separately or within the agreed project scope. The administrator and business owners need a route for questions, changes and future upgrades.
- Review requested changes against the agreed process and their maintenance impact.
- Keep configuration records, user access and upgrade testing responsibilities current.
Sources & further reading
A useful next step
Bring one real workflow.
A sample document, the systems you use and the decision you need to make are enough to start a focused conversation.
Talk to Lava ↗