A Surat manufacturer considering Odoo often has the same question: "We know we need a system — but what actually happens once the project starts?" The phases sound straightforward on a brochure. In practice, each one surfaces decisions that cannot be delegated to the implementation partner. This article walks you through the full project lifecycle so you can enter it with realistic expectations.
Why the scoping phase is the most important thing you will do
Before any configuration begins, a competent implementation partner will spend time understanding how your plant actually runs — not how you wish it ran. This is called the discovery or scoping phase, and it typically involves structured workshops with your production, stores, purchase, accounts and sales teams.
The output is a document variously called a Business Requirement Document (BRD) or a Functional Specification. It maps your current processes to what Odoo's standard modules can handle, identifies gaps, and lists customisations that would be needed.
What you must decide here:
- Which processes are genuinely core to your business versus inherited habits that could change?
- Are you willing to adapt your process to fit Odoo's standard flow, or do you need custom development for certain steps?
- Which departments go live in the first phase, and which in a later phase?
The honest answer to the second question has a direct bearing on cost and timeline. Standard Odoo is powerful; unnecessary customisation is how projects run over time and budget.
Modules a manufacturing company typically activates
Odoo is modular. A manufacturer does not need to activate everything at once. The modules most commonly needed for a production environment are:
- Inventory — stock locations, multi-warehouse, lot and serial tracking
- Manufacturing (MRP) — bills of materials, work orders, routings, production orders
- Purchase — vendor management, purchase orders, goods receipt
- Sales — quotations, sales orders, delivery scheduling
- Accounting — integrated financial posting from every transaction
- Quality — inspection checkpoints, non-conformance recording
- Maintenance — planned and corrective maintenance for plant equipment
For companies that job-work or run contract manufacturing, the Subcontracting feature within MRP becomes important. For those with multiple plants or godowns across Surat or nearby areas, multi-location inventory configuration matters from day one.
A detailed look at how these modules work together in a production context is covered in our manufacturing ERP solutions overview.
Data readiness: the part most companies underestimate
The implementation partner can configure Odoo correctly and still deliver a broken go-live if your master data is not clean. This is the most common source of post-go-live problems in Indian manufacturing companies.
Master data you will need to prepare:
Item master
Every raw material, semi-finished good, and finished product needs a unique code, a unit of measure, and a defined storage location. If your current system uses inconsistent naming — same item under three names, duplicate codes — clean it before migration, not after.
Bill of materials (BoM)
Each finished product needs an accurate BoM with correct quantities and the right unit of measure for each component. If your production team works from informal recipes or the BoM exists only in someone's head, extracting and validating it is your responsibility, not the implementer's.
Vendor and customer master
GST numbers, HSN codes, payment terms and bank details need to be accurate. Errors here create compliance problems from the first invoice.
Opening stock and balances
Decide a cut-off date. On that date, physical stock counts must be done, valued correctly, and entered as opening stock. Outstanding purchase orders, sales orders, and accounting balances also need to be migrated.
Assigning a dedicated internal data owner — usually a senior stores or accounts person — and giving them time to work on this is non-negotiable.
Configuration and development: what happens in the middle weeks
Once scoping is signed off and data preparation is underway, the implementation team configures Odoo to match the agreed functional specification. This includes:
- Setting up the company structure, warehouses, locations and operating units
- Configuring manufacturing routings and work centres to reflect your shop-floor layout
- Defining approval workflows for purchase orders, quality checks and production orders
- Setting up the chart of accounts, tax groups, and GST return configuration
- Building any custom reports — daily production summaries, job-card formats, dispatch challans — that are not covered by Odoo's standard output
If custom development is in scope, it runs in parallel. Custom code should be reviewed against Odoo's upgrade path — poorly written customisations can make future version upgrades expensive.
During this phase, your core team members (the people who will actually use the system) should be involved in reviewing configurations, not just the IT lead. A stores supervisor who sees the goods receipt flow for the first time only at go-live is a risk.
User acceptance testing: the dress rehearsal
User Acceptance Testing (UAT) is a structured period — typically two to four weeks — in which your team runs real business scenarios through the configured system before it goes live.
Good UAT covers end-to-end flows: a purchase order raised, goods received into stock, production order created against it, finished goods produced and quality-checked, dispatched against a sales order, and invoiced. Each step should produce the right document, the right stock movement, and the right accounting entry.
What you must decide during UAT:
- Which issues are genuine defects that must be fixed before go-live?
- Which are change requests (things not in the original scope) that should be logged for a later phase?
- Is the system stable enough to proceed, or does go-live need to be pushed?
The pressure to go live on a fixed date is real, but going live on a broken system is far more disruptive than a two-week delay. This is a call only the business owner or plant head can make.
Plant-floor rollout: the practical challenges
For a manufacturing company, ERP adoption on the shop floor is different from adoption in an office. Production supervisors and store-keepers may not be comfortable with computers. Shift work means training cannot happen in a single session.
Practical approaches that work:
- Role-specific training: a machine operator who confirms a work order needs to know only that transaction. Training everyone on everything wastes time and creates confusion.
- Printed quick-reference cards for the three or four transactions each role does daily.
- A go-live buddy system: pair each shop-floor user with a slightly more system-comfortable colleague for the first two weeks.
- Running parallel for a short period: some manufacturers run the old system alongside Odoo for two to four weeks for high-value or high-risk transactions. It adds workload but reduces the cost of errors.
For companies looking at how Odoo ERP can be configured for a manufacturing environment, the plant-floor user interface is worth evaluating early — Odoo's manufacturing module has dedicated shop-floor views designed for this context.
Go-live and the weeks immediately after
Go-live is not the end of the project. The four to six weeks after go-live are the highest-risk period. Stock discrepancies surface. Users find edge cases not covered in training. Accounting entries look unfamiliar. Some processes that were clear in UAT become confusing under production pressure.
During this period you need:
- An implementation partner with committed post-go-live support hours, not just a ticketing system
- An internal point-of-contact who can triage issues and decide what is urgent
- Patience from management — the first month of live data is rarely clean, and that is normal
Odoo's implementation process for Surat-based businesses should include a defined hypercare or stabilisation period in the contract. Confirm this before signing.
What only the owner or plant head can decide
Throughout the project, certain decisions are routinely blocked because they cannot be made by the IT team or the implementation partner. These are business decisions:
- Scope changes: if a department head asks for a new feature mid-project, someone with authority must decide whether it goes into this phase or the next.
- Process changes: if Odoo's standard flow requires your purchase team to work differently, someone must decide whether to adapt the process or pay for customisation.
- Data disputes: when two departments disagree about which item code or BoM version is correct, a decision-maker must resolve it.
- Go/no-go at UAT: as described above, this cannot be delegated.
Projects where senior leadership stays distant from the implementation consistently take longer and cost more. Your time commitment as owner or plant head is part of the project budget, even if it does not appear on the invoice.
If you are still evaluating whether this kind of project is the right fit, an ERP consulting engagement before committing to implementation can help you answer scope and readiness questions without pressure.
Starting the conversation
If you are a manufacturer in Surat at the stage of asking "what does this actually involve?", the most useful next step is a structured pre-implementation discussion — covering your current processes, your data readiness, and a realistic project scope.
We work with manufacturing companies from our base in Surat and are straightforward about what a project will require from both sides. Reach out to discuss your requirements and we will help you build a clear picture before any commitment is made.