The phase everyone skips
A client calls me in mid-project. The vendor has been configuring for three weeks. The sales module is set up. The inventory module is set up. The problem: the client's sales process involves three approval layers, a customer credit check tied to accounts receivable, and a currency conversion that happens at a different exchange rate than the system default. None of this was captured before configuration started.
The vendor is not incompetent. They just started on the wrong end. They opened Odoo first and mapped the business second — which is like writing a building's floor plan after pouring the foundation.
Discovery is the period — typically two to four weeks — before any configuration happens. Its only job is to understand how the business currently operates, how it wants to operate after the ERP, and what the gap between those two states looks like. That gap is the project scope.
Open the business first. Open Odoo second.
Before you schedule a session
Most discovery failures happen before the first interview. The client isn't ready — no designated project owner, no documents, no executive cleared for two hours. A readiness check before Day 1 is not bureaucracy; it is risk management.
Questions to ask the client before booking sessions:
| Question | Why it matters |
|---|---|
| Do you have a designated project owner on your side? | If no — stop. Don't start. Without internal ownership, decisions stall and scope grows by default. |
| Has executive leadership committed 2 hours for a discovery kick-off? | Without executive presence, departments sandbag and cross-functional conflicts go unresolved. |
| How many legal entities, warehouses, or production sites? | Sets session count. Each site with distinct processes needs its own sessions. |
| What software do you currently use — ERP, Excel, custom systems? | Maps data migration scope before a single question is asked. |
| Do you have written SOPs for any process? | Confirms how much undocumented process you're walking into. |
| Can you share a completed sales order and a vendor invoice from last month? | Real documents reveal what the verbal description hides — approvals, exceptions, fields. |
Documents to collect before sessions begin:
- Last 3 months of purchase orders (any format)
- A completed sales order — from creation through invoice and payment
- The most recent bank reconciliation worksheet
- Org chart (even an informal one hand-drawn on a napkin)
- Chart of accounts or a recent P&L statement
- Any existing IT system documentation or user manuals
If the client can't provide a single completed document before Day 1, the process exists only in people's heads. Budget extra time — every session will require more probing and every sketch will need a second validation round.
Four things you're mapping
A complete discovery produces four artifacts. Miss any of them and you'll find the gap during UAT — which is the most expensive place to find it.
Process flows (as-is)
Who does what, in what sequence, with what inputs and outputs. Draw it — even a whiteboard sketch counts. The act of drawing surfaces assumptions that verbal descriptions hide.
Data entities & master data
What lists does the business run on: products, customers, vendors, chart of accounts, warehouses, production routes. Their current state — volume, quality, format — determines how long migration takes.
System touchpoints
What other systems does the ERP need to talk to? Banking portals, payroll software, customs declarations, e-commerce. Each integration is a separate scope item and a separate risk.
Roles & access rules
Who can see what, who can approve what. In Bangladesh manufacturing, this often means multi-site access rules, shift-based roles, and sometimes a hard separation between entity-level accounts visibility.
How to run the sessions
Discovery is not a requirements workshop. A requirements workshop produces a wish list. A discovery session produces a map of reality. The format I use:
The floor-level operator is the most important person in the room. Department heads describe the intended process. Operators describe the actual one. The gap between those two is where your configuration will be tested.
Ask "what happens when it goes wrong?" for every step. Exceptions and edge cases are not footnotes — they are where the real process lives. If your discovery doesn't capture them, your UAT will.
Question bank by department
The most consistent gap in consultant-led discovery: the questions aren't sharp enough. Here are the questions that surface the most important process detail, by department. Use them as a starting baseline — every engagement will add more.
Procurement
- Walk me through your last purchase order from the moment you decided to buy something.
- Who approves purchases — and what happens when they're unavailable or traveling?
- Do you track partial deliveries? What happens when a vendor delivers 80% of an order?
- How do you handle returns to vendors — is there a paper trail?
- What's the average time between raising a PO and receiving goods?
- Do you issue advance payments to vendors? How are they reconciled against the final invoice?
Finance & Accounts
- How do you currently match a vendor invoice to a purchase order and a goods receipt?
- What is your month-end close process? How many working days does it take?
- Do you operate in multiple currencies? At what point is the exchange rate fixed — PO, GRN, invoice, or payment?
- How many bank accounts do you reconcile, and how often?
- Do inter-company transactions exist between your entities? How are they currently settled?
- How do you handle tax — VAT, AIT, withholding? Is it calculated manually or through software?
Sales
- Walk me through a sale from first customer contact to invoice payment.
- Are there approval steps for quotes, pricing exceptions, or discounts? Who approves?
- How do you handle partial shipments — does the customer get a partial invoice?
- Do customers have credit limits? Who monitors them and what happens when they're exceeded?
- How are returns and credit notes processed today?
- Do you manage customer-specific pricing or contract rates?
Production & Manufacturing
- How do you plan production — based on sales orders, a weekly schedule, or something else?
- How are raw material requirements calculated? Is there a BOM? Is it written down?
- What happens when a material is short during production — who decides how to proceed?
- How do you record actual production vs. planned? Who enters it and when?
- Who signs off a finished goods entry into the warehouse?
- How do you track scrap, rework, and quality rejections?
What good output looks like
Bad discovery output is a bullet-pointed list of features the client wants. Good discovery output has three documents: (1) annotated as-is process flows, (2) a gap map that links each gap to a required Odoo configuration or customisation, and (3) a data migration inventory that records every master data entity, its current volume, quality, and target format. Miss any of the three and the configuration team is making assumptions.
Bad output — wish list
• Inventory management
• Sales order tracking
• Purchase approvals
• Multi-warehouse
No flows. No exceptions. No data volume. No roles. Useless for configuration.
Good output — gap map
As-is: Procurement raises PO in Excel → manager WhatsApp approval → vendor delivers → manually entered in Tally.
Gaps: No 3-way match today. Partial GRN not tracked. FX not captured at PO date.
Odoo config required: Purchase → Inventory → Accounting integration + approval workflow.
The gap map is the project scope. If the vendor's statement of work doesn't map back to a gap-by-gap list, you don't have a project — you have a verbal agreement that will be interpreted differently on both sides.
A useful gap map follows this structure. Here's a minimal working example from a procurement discovery:
| Step | As-is | Exception | Odoo mapping | Gap | Priority |
|---|---|---|---|---|---|
| PO creation | Excel, emailed to manager | Urgent orders verbal only | Purchase → RFQ → PO | No approval workflow today | HIGH |
| GRN | Paper receipt, filed weekly | Partial deliveries not tracked | Purchase → Receipts | Partial GRN logic needed | HIGH |
| Vendor invoice match | Manual comparison in Excel | Advances paid before invoice | Accounting → Vendor Bills | 3-way match not done today; advance reconciliation needed | HIGH |
| FX rate | Rate at payment date, manually entered | LC rate locked at opening | Multi-currency in Accounting | Rate locking at PO date required for LC orders | MED |
| Vendor returns | Rarely happens, no formal process | — | Purchase → Returns | Process to design from scratch | LOW |
Estimating your discovery scope
One of the first questions a client asks: how long will discovery take? A reliable heuristic: one 90-minute session per major department per Odoo functional area that department touches. A procurement department that touches Purchasing, Inventory, and Accounting needs three sessions, not one.
| Deployment size | Modules | Departments | Sessions needed | Discovery duration |
|---|---|---|---|---|
| Small | 2–3 | 2–3 | 6–8 | 1 week |
| Mid-size | 4–6 | 4–6 | 12–16 | 2–3 weeks |
| Large | 7+ | 7+ | 18–24+ | 4–6 weeks |
On pricing discovery as a standalone phase: discovery should be sold as a separate deliverable with its own invoice — not bundled into the implementation fee. When bundled, it is the first thing cut when a client tries to reduce scope. A separate engagement creates mutual accountability. The consultant must deliver complete documentation. The client must show up and provide access.
If a vendor offers "free discovery," ask what documentation they deliver at the end. Free discovery is almost always a sales demo with a statement of work attached. It produces a wish list, not a process map.
The handoff to configuration
Discovery ends with a formal handoff session where the BA walks the configuration team through every gap, every exception, and every data migration requirement — in writing. This session should take half a day. If it takes less, something wasn't captured.
Three things must be resolved before configuration starts:
- Scope freeze. Any new requirement after this point is a change order with a timeline impact. Both sides must agree to this in writing.
- Data migration owner named. The client names one person responsible for delivering clean master data by a fixed date. The consultant names the import format. A date is set.
- UAT entry criteria defined. What does "ready for UAT" mean? Which flows must pass, at what fidelity, before end-users are invited to test? If this isn't defined upfront, UAT never ends.
For the BPMN templates I use during manufacturing discovery, there's a starter pack in Lab 0010 — built for Week 1 of every engagement. The UAT scripting guide picks up where discovery hands off in Lab 0009.
What goes wrong in discovery itself
Discovery is not automatically good just because you scheduled it. The four most common ways consultants run discovery badly:
Scoping to the demo
The consultant opens Odoo and asks "can your process fit this screen?" instead of mapping the process first and then checking fit. This produces a scope that conforms to Odoo's defaults — not the client's business. Every customisation surfaces as a surprise in UAT.
The IT head speaks for everyone
IT knows the systems. They don't know the process. In many businesses, the IT coordinator becomes the proxy for all departments "to save time." The result: a technically accurate system description with no operational reality attached to it.
Not validating the sketch
A session produces a process sketch. Nobody sends it back to the operator for confirmation. Two weeks later in configuration review, a key exception surfaces that the BA missed. The sketch felt complete in the room. It wasn't.
Capturing the desired future state
Clients instinctively describe how they want things to work, not how they currently work. Discovery that maps the desired state is requirements-gathering in disguise — it produces gaps against a fantasy, not against reality.
Bangladesh-specific considerations
Bangladesh manufacturing and trading businesses have structural patterns that almost never appear in Western ERP methodology guides. Missing them during discovery means finding them during go-live.
Shadow processes and paper registers
In garment, ceramics, food processing, and trading businesses, the formal process described by management is often a skeleton. The operational reality lives in WhatsApp group approvals between managers, Excel sheets maintained by individual staff members rather than the company, paper registers at factory floor level reconciled weekly or never, and verbal sign-offs for urgent orders that bypass the official approval chain.
This is precisely why the floor-level operator rule is non-negotiable. A discovery that interviews only department heads will miss the majority of actual process paths. The question to ask every operator: "Show me the last five times this happened. Walk me through each one."
Multi-entity complexity
Dhaka-based groups commonly have 3–8 legal entities: a trading company, one or more manufacturing units, an export company, and a holding entity. They often share staff, physical resources, and sometimes bank accounts. Discovery must explicitly establish: which entities go live in Phase 1, which inter-company flows must be automated from Day 1, and which can be handled manually through the transition period. Leaving this question open is the single fastest way to cause the go-live to slip.
FX and LC-based procurement
USD-BDT transactions, letter-of-credit procurement, and advance payments against imports introduce exchange-rate timing complexity that most ERP configurations ignore until UAT. Capture it explicitly during the finance discovery session: at what point is the rate locked — PO date, LC opening date, GRN date, invoice date, or payment date? Each business has a different answer, and each answer requires a different Odoo configuration.
NBR compliance touchpoints
VAT calculation under the NBR regime, Mushak forms, and AIT on vendor payments are not afterthoughts — they surface inside procurement, sales, and finance processes. Flag every step where a tax implication exists during discovery. It's far cheaper to map them to the right Odoo module during discovery than to retrofit them after go-live.
FAQ
What is an ERP discovery session?
An ERP discovery session is a structured workshop where the implementation team maps current business processes before any system configuration begins. It spans 2–5 days across every department that will use the ERP, producing a process inventory, a gap list, and a configuration blueprint that becomes the project scope.
Who should attend an ERP discovery workshop?
Department heads and key users from every function the ERP will touch — finance, procurement, production, sales, HR, and IT — plus at least one floor-level operator per department. Executive sponsorship is essential to resolve cross-functional conflicts on the spot. Consultants facilitate; internal users provide the process knowledge.
How long does business process mapping take before Odoo configuration?
For a mid-size Bangladesh manufacturer deploying 4–6 Odoo modules, discovery and process mapping typically takes 2–4 weeks including workshops, documentation, and stakeholder sign-off. Skipping this phase is the single biggest cause of scope creep and failed implementations.
Can discovery be done remotely?
Yes, with caveats. Remote discovery works well for process interviews. It fails for floor-level observation — which is irreplaceable in manufacturing. A hybrid format (remote interviews + one on-site day at the factory) is the minimum viable approach for any manufacturing deployment. Fully remote discovery works only for service businesses with no physical operations.
What's the difference between a discovery session and a requirements workshop?
A requirements workshop starts with what the client wants. A discovery session starts with how the business currently operates. Discovery produces a map of reality. Requirements workshops produce a wish list. You need the map before you can evaluate the wishes — otherwise you're configuring against a fantasy.
Should discovery be a paid engagement?
Yes. Always. Discovery that is bundled free into implementation is always cut first. A paid discovery creates accountability on both sides: the consultant must deliver documentation; the client must show up. It also protects the consultant — if the client cancels after discovery, there is a documented deliverable, not a lost sales conversation.
What is a process gap in ERP terms?
A gap is the difference between how the business currently operates and how the target ERP system works out of the box. Gaps require one of three responses: configure the ERP to fit the process, adapt the process to fit the ERP, or build a custom extension. Discovery's job is to identify every gap so the project team can make those decisions — deliberately, before configuration starts, not reactively during UAT.
How do you handle conflicting process descriptions from different departments?
Document both versions, flag the conflict explicitly in the gap map, and escalate to the executive sponsor in the handoff session. Do not pick a version yourself as the consultant — you don't own the business process. The client must decide. If they can't decide during discovery, that unresolved conflict is a scope risk: write it down as such, with a timeline impact estimate attached.
If you're starting an Odoo engagement and want a scoped discovery — not a demo — let's talk →. Want a ballpark budget before you commit? The free Odoo Cost Estimator gives a Bangladesh-specific range in 60 seconds.