Odoo implementation guide (Bangladesh)

How to use this guide

Read it in order if you are starting from zero. If a phase is already done, use that section to check what is still open. Pair it with the ERP readiness checklist and the Learning Center when you need a shorter path.

1. Agree the first release before anyone configures a database.
2. Name an owner for each process and for master data.
3. Treat customization as an exception, and write down why it exists.

Phase 1: Discovery and scope

A useful first release is the smallest set of workflows that the business will actually run on day one. Garments traceability, a multi-warehouse distributor, a retail counter, and a services firm do not share that set. Start from the industry page that matches the operation, then pick modules, instead of turning every app on.

• Write success metrics the team can check: order cycle time, stock accuracy, invoice lag, or month-end close. Avoid “implement ERP” as the metric.
• List must-have workflows per department, and mark everything else out of scope for the first release.
• Use the garments, distribution, retail, and services pages to see which modules usually show up together.

Phase 2: Process mapping

Document the current process before designing the next one. The gap between them is the change people have to learn, and it is also where approvals, discounts, and stock moves get lost.

• Record the as-is steps, including the spreadsheet or WhatsApp step that sits beside the current system.
• Design the to-be process with a named approver for price, purchase, and credit decisions.
• List the reports managers will ask for in the first month, and confirm the fields those reports need.

Phase 3: Data readiness

Most go-live delays in this kind of project are data delays. Products, customers, vendors, and the chart of accounts need owners before migration rehearsals start. Confirm the company’s financial year before opening periods. In Bangladesh that year is often July to June, but the legal entity’s own year is the one that matters.

• Assign owners for products, customers, vendors, and the chart of accounts.
• Clean duplicates and units of measure before the first trial import.
• Plan VAT invoicing as a workflow, not as a last-week setting. The accounting module page covers the finance decisions that sit next to stock and sales.
• Run at least one full dry-run migration, then a final cut, instead of a single import on go-live weekend.

Phase 4: Configuration and customization

Configure the standard flow first. Customize when a documented process cannot be covered by settings, and keep that customization small enough to test. Inventory routes, manufacturing bills of materials, and point-of-sale payment methods are common places where configuration is enough.

• Review scope module by module in the modules directory, starting with the apps in the first release.
• Write down each customization: the process it serves, the owner, and how to test it.
• List integrations separately (bank, eCommerce, logistics) and decide which ones wait until after go-live.

Phase 5: Testing and training

User acceptance testing should follow the real documents: a quotation that becomes a delivery and an invoice, a purchase that becomes a receipt and a vendor bill, a shop-floor order that consumes components. Train people by role, on those same flows.

• Write UAT scripts for the critical flows only. A script that nobody runs is not a test.
• Point finance users at functional accounting training, warehouse teams at inventory, and developers at module development. The broader paths sit on the training page.
• Train system owners on how to add a user, a tax, and a product, not only on day-to-day entry.

Phase 6: Go-live and stabilization

Go-live is a cutover, then a short period of close support. Keep a rollback point for master data, freeze non-critical changes, and park improvements that can wait until the first month-end is closed.

• Publish a cutover checklist: who stops the old process, who imports the final stock and open documents, and who signs off.
• Name a hypercare window and the person who triages issues each day.
• After the first close, review the improvement list instead of adding scope during the first week.

Common pitfalls

• Starting from custom code before the standard flow has been tried.
• Importing dirty product and partner data because the go-live date was announced first.
• Leaving approvals and pricelists “to be decided in training.”
• Treating this guide as a quotation. Cost components belong on the pricing guide, and product choice belongs on the comparisons.