Around Odoo and the systems next to it, Openstone works in four ways. Clients often ask "what exactly do you do — which of these is for my situation?" This article spells all four out, including what we refuse, and ends with a decision table.
1. Odoo implementation
What it is: end-to-end delivery from discovery to go-live training — mapping processes, designing the solution, configuring the system, migrating opening data, training users and shepherding the launch.
Who it suits: teams with concrete scenarios ready to put sales, purchasing, inventory, manufacturing or finance onto a system.
What it delivers: discovery and process mapping, solution design and configuration, opening-data migration, user training and go-live support — each phase's deliverables (the diagnosis note, the configuration list, and so on) confirmed together with you.
What it refuses: turnkey promises. Implementation takes both sides — your team contributes in discovery, data, training and trial runs, and milestones are confirmed jointly. Projects in the shape of "you do everything, we wait to use it" are not how we work.
2. Custom development
What it is: module development and customization on the Odoo framework — business rules, document formats, approval flows and industry specifics the standard features do not cover.
Who it suits: teams with clearly defined custom rules, willing to trade a little for maintainability.
What it delivers: custom modules, reports and documents, UI and access-control customization, and migration work at version upgrades.
What it refuses: rewrites that fight the Odoo core. Customization must stay upgradeable and maintainable — burying everything in a forked, mutant copy locks away future upgrades. That is not customization; it is technical debt.
3. System integration
What it is: connecting the ERP with the surrounding systems — e-commerce, logistics, payment, tax, BI — so data stops being carried by hand.
Who it suits: teams running several systems in parallel, shuttling data by exports and imports.
What it delivers: API design and development, connectors for common systems, data sync and reconciliation, integration monitoring.
What it refuses: forcing connections onto systems with no API capability. We assess the other side's openness first (API, database, file exchange) and design from there; a "forced" integration will not survive the counterpart's next upgrade.
4. Managed operations
What it is: on-premise or cloud deployment, monitoring and backups, security hardening and version upgrades — keeping the system running steadily.
Who it suits: systems already live without dedicated operations staff, or teams with security and stability requirements.
What it delivers: deployment and containerization, monitoring and alerting, backup and recovery drills, security hardening and upgrades.
What it refuses: unattended hand-off. Changes, upgrades and recovery drills are scheduled together with you — the value of operations is execution discipline, not transferring responsibility.
Decision table: which route is mine?
| Your situation | Suggested route |
|---|---|
| Standard flows; just want to start fast | A Hongzhai Cloud ERP subscription (ready out of the box, annual) — no project needed |
| Mostly standard, a few special flows | Subscription as the base + custom development for the exceptions |
| New to systems; processes need sorting first | Start with implementation (includes process mapping and training) |
| Already live; "data moves by hand" | System integration |
| No dedicated ops; worried about security and backups | Managed operations (combinable with any of the above) |
Two general notes: service projects are scoped, quoted and planned in writing; and standard needs and tailored needs combine — a subscription for the core plus customization for specific flows is our most frequent recommendation.
One line
All four share the same habit of "saying it clearly": what we do, what we refuse, what we deliver — on paper before starting. If you are unsure which route is yours, contact us — the first conversation is about classifying the problem.