Why This Guide Exists
Every consulting firm and ERP vendor will tell you that process mapping is important. Almost none of them will tell you how to do it, in detail, with the specificity that lets you actually run the sessions, build the documents, and defend the scope to a skeptical Managing Director.
This guide is the one I wish I had at the start of my first ERP engagement. It covers the full methodology — not just the theory. It includes the exact questions I ask in discovery interviews, the gap register structure I use on every project, real examples drawn from Bangladesh manufacturing and trading companies, and a full account of the mistakes I have personally seen derail implementations.
By the end, you will be able to run an AS-IS to TO-BE mapping engagement from first session to signed gap analysis document. This is not a 10-minute overview. It is a complete practitioner's reference.
This guide assumes you understand what an ERP is and why companies implement them. If you're new to the ERP discovery process, read that article first. If you want BPMN diagram templates for Bangladesh manufacturing contexts, see Lab 0010.
What AS-IS and TO-BE Really Mean
The terms are simple. The concepts are not. Most failed projects fail not because the team didn't know the terms, but because they applied them incorrectly. Let me be precise.
The AS-IS State
The AS-IS is the unfiltered, honest, ground-level reality of how your business operates today. Not how management thinks it operates. Not how the SOP manual says it should operate. How it actually operates — the WhatsApp approvals, the Excel workarounds, the paper registers, the verbal agreements, and the shadow systems that exist because the official process breaks down.
- Includes every manual step and workaround
- Includes exceptions as well as the standard path
- Includes unofficial tools and communication channels
- Includes pain points, delays, and error-prone handoffs
- Sourced from operators, not managers
The TO-BE State
The TO-BE is your designed future workflow — how the business will operate inside the ERP after go-live. It is not a screenshot of Odoo's default behavior. It is a deliberate design that maps your business logic onto the ERP's capabilities, eliminating identified waste and automating identified manual steps.
- Eliminates waste identified in the AS-IS
- Maps your business rules onto ERP capabilities
- Accounts for your industry's specific compliance needs
- Is achievable within the ERP (native, configured, or customized)
- Approved by process owners, not just management
The relationship between the two states is where the real insight lives. The delta between AS-IS and TO-BE is the project scope. Every item in that delta is a task: a configuration to build, a process to change, or a custom module to develop. If your gap analysis is complete, your statement of work is complete. If it is not, your statement of work is a guess.
The gap between AS-IS and TO-BE is not a problem to minimize. It is the project.
A second common mistake: treating TO-BE as "the Odoo standard." Odoo has default workflows. But "default" was designed for a generic business. Your business is not generic. A Bangladesh RMG company with a 5-tier approval structure for overseas LCs cannot simply adopt Odoo's out-of-the-box purchase approval. The TO-BE must be your process, designed by you, enabled by Odoo — not the other way around.
Before Phase 1: Setting Up for Success
A discovery engagement that starts without preparation produces bad data. You show up to the first interview and the department head has no idea what you need. You ask for documents and spend a week chasing them. The session produces wish lists instead of process descriptions. Protect against this with a structured preparation week.
Assemble the Right Team
Process mapping is a team sport. You need:
Document Request List
Send this list at least one week before discovery starts. Receiving the documents in advance — even partially — dramatically improves session quality because you can ask informed questions instead of starting from zero.
Stakeholder Briefing
Before the first session, brief the project sponsor and all department leads on what discovery is and what it is not. Left unbriefed, department heads will treat the session as a product demo request and produce wish lists. Set these expectations explicitly:
What discovery is NOT
It is not a feature request session. It is not a demo of the new system. It is not a chance to redesign the entire company. It is not the place to debate whether you should have bought the software.
What discovery IS
It is a structured interview to understand how work currently flows through your department — step by step, including every exception, workaround, and approval. The output is a process map, not a feature list.
Phase 1: The AS-IS Discovery
This is the most important phase of the project. The fidelity of your AS-IS map determines the quality of everything that follows: the TO-BE design, the gap analysis, the configuration spec, and the UAT script. Compress it, and the project pays the cost downstream — at UAT, at go-live, or both.
Step 1: The Gemba Walk
"Gemba" is a Japanese manufacturing term for "the actual place." A Gemba Walk means physically walking the process — following a single transaction from start to finish, in real life, on the factory floor or in the office, watching it happen.
This is not optional. It is the single most effective discovery technique I know. Every interview I have ever conducted was improved by the Gemba walk I did before it. Here is why: people describe the process they think they run. Walking the floor shows you the process they actually run — and the gap between the two is often enormous.
In Bangladesh manufacturing, the Gemba walk often reveals critical hidden steps: delivery challans being counter-signed by a store manager who is not in the org chart, production job cards being maintained in a physical register that no one mentioned, or LC documents being processed through a WhatsApp group that includes three external parties. None of these will appear in an interview unless you saw them first.
Pick a single representative transaction for each major process area and follow it end-to-end. For procurement, start with a purchase requisition and follow it until the supplier invoice is posted. For production, start with a sales order and follow it until the finished goods are dispatched. Note every handoff, every document created or received, every system touched, every person involved.
Step 2: The Discovery Interview — Format and Facilitation
The interview session is where the map is built. Run one session per department. Do not combine departments — the dynamics change and cross-departmental tensions produce politically edited answers, not honest ones.
The floor-level operator is the most important person in the room. Every department head will describe the intended process. The operator will describe the actual one. Direct the questions to the operator when you need to understand exceptions and workarounds. Direct them to the department head when you need to understand approval authority and business rules.
Step 3: The 7 Discovery Questions
These questions work across every function — procurement, sales, production, finance, HR. Ask them in sequence for each major process step. The follow-ups are as important as the questions themselves.
Q1: "Walk me through what happens when [trigger event] occurs. What is the very first step?"
Why: Gets the process started. Forces specificity. "We process the order" is not an answer. "The sales executive receives the email and enters it in the register" is.
Q2: "Who does this step? What is their exact role and title? Who else can do it?"
Why: Maps role-to-task. Reveals single points of failure (only one person can approve). Critical for access rights configuration later.
Q3: "What information do you need to complete this step? Where does that information come from?"
Why: Identifies data inputs and their sources. Reveals hidden dependencies between departments. Uncovers shadow systems (WhatsApp messages, phone calls, separate spreadsheets).
Q4: "What do you produce at the end of this step? A document? A record? A notification? Who receives it?"
Why: Identifies outputs and handoffs. Every handoff is a potential automation point in the ERP. Every paper document is a data entry burden to eliminate.
Q5: "How long does this step normally take? What causes it to take longer?"
Why: Quantifies the pain. A step that "normally takes 2 days but sometimes 2 weeks" is a critical gap candidate. Volume and duration data also drives ROI calculations later.
Q6: "What goes wrong here? What are the most common errors or exceptions?"
Why: Exceptions are not footnotes — they are where the real process lives. Every exception is a business rule that must be captured in the TO-BE design. The standard path is easy; exceptions are where ERP implementations collapse during UAT.
Q7: "Is there anything in this process that you think is unnecessary, broken, or just done 'because we've always done it'?"
Why: Opens the door to process improvement. Sometimes operators know exactly which steps are waste but have never been asked. This seeds the TO-BE workshop.
Never accept a vague answer and move on. "We get approval from management" is not specific enough. Who? Which level? How long does it take? What happens if they are traveling? What is the minimum amount that requires approval vs the amount that doesn't? Every vague answer is a gap that will surface during UAT at the worst possible time.
Step 4: Document Artifact Collection
After each session, collect every physical artifact associated with the process. Walk to the person's desk and ask them to show you. This step is routinely skipped and routinely regretted.
Step 5: Drawing the AS-IS Map — BPMN Basics
Your AS-IS process map must be a formal diagram, not a handwritten sketch. It needs to be readable by your client, your configuration team, and a third-party auditor. The industry standard for this is BPMN 2.0 (Business Process Model and Notation). You do not need to master every BPMN symbol. You need the five core elements:
Use swim lanes religiously. The swim lane view instantly makes visible every handoff across department boundaries — and handoffs are where delays, errors, and duplicate work accumulate. In a typical Bangladesh manufacturing procurement process, you will find 6–9 handoffs between Purchase, Accounts, Store, and Management. Each one is a candidate for automation.
Recommended tool: Draw.io (diagrams.net). It is free, browser-based, requires no installation, has BPMN shape libraries built in, and produces files that can be shared without a paid license. For most Bangladesh projects, this is the right choice. If the client has a Lucidchart or Microsoft Visio license, use those instead — the principle is the same.
Draw the map collaboratively. Project it on a screen during the interview session and draw in real time. When participants see the map taking shape, they immediately correct errors and add detail. A map drawn after the meeting from notes alone misses 20–30% of the nuance.
Step 6: AS-IS Validation and Sign-Off
Once the AS-IS maps are drafted, run a dedicated validation session with each department. Show them the map and ask one question: "Is this accurate?" Do not ask if they are happy with the process. Do not ask if they want to change it. Ask if the map reflects reality.
Common corrections at validation:
- A step that was described as sequential turns out to happen in parallel
- A role that was named is actually split between two people on different shifts
- An exception that was mentioned briefly is actually the majority of cases
- An approval step that exists on paper does not happen in practice
After all departments have validated their maps, get formal written sign-off (even an email) from the department head and the project sponsor. This is the AS-IS baseline. Any future claim that "the process has always worked this way" can be measured against it. The AS-IS sign-off also freezes the scope of what is being changed — without it, the discovery phase never truly ends.
Phase 2: Designing the TO-BE State
The TO-BE design phase is where the Business Analyst shifts from recorder to architect. You are no longer just documenting — you are designing. The discipline required is different: you must challenge assumptions, eliminate waste, and hold your ground when people want to rebuild the old process in a new system.
Lean Principles Applied to Office and Factory Processes
Lean manufacturing identifies seven forms of waste (Muda). Every one of them applies to office and administrative processes — not just the factory floor. Use this framework to evaluate every step in your AS-IS map:
Overproduction
Generating reports nobody reads. Printing documents that go straight into a drawer. Creating purchase orders for items already in stock.
Waiting
A purchase order sitting in an inbox waiting for approval. An invoice on hold because the GRN isn't done yet. A production order delayed because the BOM hasn't been updated.
Transport
Walking a paper form from one desk to another. Emailing a file for someone to print, sign, scan, and email back. Physical handoffs that add no value.
Over-processing
Five-layer approval for a $50 purchase order. Three copies of the delivery challan when one would suffice. Data entered in three separate systems.
Inventory
In process terms: information queued up and waiting. Unprocessed purchase requests. Unreviewed expense claims. Unposted journal entries. WIP that doesn't move.
Motion
Searching for information that should be centrally available. Re-entering data that already exists in another system. Looking up customer credit terms that should surface automatically.
Defects
Manual data entry errors. Invoices posted with wrong amounts. Stock adjustments covering counting mistakes. Every defect has a cost — find them in the AS-IS before they migrate to the TO-BE.
For each AS-IS step, ask: which waste category does this step exhibit? Steps with no waste are kept. Steps with waste are redesigned in the TO-BE — either automated, eliminated, simplified, or consolidated.
The TO-BE Design Workshop
Do not design the TO-BE alone. Run a structured workshop with the department leads, the project sponsor, and the lead configurator (the Odoo consultant who will build the system). The BA facilitates; the others contribute.
The most important facilitation skill is pushing back on "we need it to work exactly like it does today." This phrase will appear in every session. It is sometimes legitimate (a compliance requirement with no flexibility) and sometimes pure inertia ("it's how we've always done it"). Your job is to tell the difference.
When someone says the process must stay as-is, ask: "If we didn't have this step, what would break?" If they can name a specific consequence — a regulatory requirement, a contractual obligation, an audit finding — keep the step. If they cannot name a consequence, the step is a candidate for elimination or redesign.
TO-BE Design by Process Area
The specific design questions vary by function. Here are the key questions for each major area in a typical Bangladesh manufacturing or trading company:
What TO-BE Is NOT
Three specific things that will corrupt a TO-BE design if left unchecked:
- A wish list. "It would be nice if the system could automatically send WhatsApp messages to customers" is not a TO-BE requirement unless someone is willing to scope, budget, and test it. Every addition to the TO-BE is a scope item. Treat it accordingly.
- A copy of the AS-IS. If your TO-BE map is identical to the AS-IS map with the word "Odoo" inserted, you have not designed anything — you have digitized a broken process. Every AS-IS step must be re-evaluated against the waste framework. The default answer should be "can we improve this?" not "can we replicate this?"
- Odoo's default behavior. If your TO-BE design is just a walkthrough of Odoo's standard modules, you have not adapted the system to the business — you have adapted the business to the system's defaults. Sometimes this is the right call. It should be a conscious decision, not an accident of shallow TO-BE design.
The Gap Analysis: Turning Mapping Into Scope
The gap analysis is the document where discovery meets execution. It is the formal record of every difference between the TO-BE design and the ERP's native capabilities, along with a decision on how each gap will be closed. Without it, scope is undefined. Without defined scope, the project has no boundary, and scope creep is inevitable.
Building the Gap Register
The gap register is a structured spreadsheet. Every gap identified during TO-BE design is logged as a row. The columns capture everything needed to understand, decide, and track the gap through implementation.
Minimum columns for a usable gap register:
| Column | What to Capture | Example |
|---|---|---|
| Gap ID | Sequential reference (G-001, G-002). Used for tracking and cross-referencing with configuration specs. | G-017 |
| Process Area | Which functional area the gap belongs to. | Procurement |
| AS-IS Description | How the business does it today. Concrete and specific. | LC documents tracked in a separate Excel workbook maintained by the Accounts team |
| TO-BE Requirement | What the ERP needs to do. Written as a requirement, not a feature request. | All LC documents must be attached to the corresponding purchase order and tracked with expiry date alerts |
| Odoo Capability | What Odoo can do natively in this area. | Document attachment on PO is native. LC-specific fields and expiry alerts are not. |
| Gap Type | Category of the gap (see below). | Configuration + Development |
| Decision | How the gap will be closed: change business / workaround / develop. | Develop: add LC tracking fields on PO + email alert for expiry <30 days |
| Effort Estimate | Development hours, configuration effort, or business change effort. | 8–12 dev hours |
| Priority | Must-have for go-live / Nice-to-have / Future phase. | Must-have |
| Owner | Who is responsible for resolving this gap — client or consultant. | Consultant (development) |
| Status | Open / In progress / Resolved / Deferred. | Open |
Gap Categories
Every gap falls into one of four categories. The category determines the type of work required to close it — and different categories carry very different risks and costs:
Odoo can do this natively — if configured
The feature exists in Odoo but has not been enabled or is set to a different default. Three-way matching, multi-currency, approval workflows, reordering rules — these are all standard capabilities. Configuration gaps are the lowest risk and lowest cost to close. They require no code, only correct settings.
Odoo can do this with significant setup work
Not just enabling a feature — requires setting up complex chart of accounts, building approval rule trees, configuring multi-company intercompany flows, or creating elaborate pricing structures. The capability is native; the implementation effort is non-trivial. Underestimating configuration gaps is a common cause of project overruns.
Odoo cannot do this natively — custom code required
The requirement cannot be met with any combination of standard features and configuration. A custom Python module or XML view override is required. Development gaps carry the highest risk: custom code must be tested, maintained, and upgraded with every Odoo version. Never accept a development gap without fully understanding the ongoing maintenance implication.
Odoo can do this — but the business process must change
The ERP has a good native way to handle this, but the current business process is incompatible with it. Instead of forcing custom code, the business should adapt its process to the ERP standard. This is almost always the cheapest, most maintainable solution — but it requires change management and often the most political resistance. This is where your relationship with the project sponsor matters most.
The 3 Decisions for Every Gap
When you present a gap to the project team, you must also present a recommended resolution. There are three choices — and they are always the same three choices, regardless of the gap:
Recommended first
Risk: Low
Effort: Change mgmt
Risk: Medium
Effort: Design
Last resort
Risk: High
Effort: Dev + QA
Custom code is a long-term debt. Only take it on when the business requirement is genuinely non-negotiable.
Real Bangladesh Examples: AS-IS to TO-BE in Practice
Theory solidifies through examples. Here are three complete AS-IS to TO-BE transformations drawn from real Bangladesh implementations, with the key gaps and decisions for each.
RMG Company — Purchase-to-Pay Process
A ready-made garments manufacturer with 1,800 workers, 3 buyers, and a procurement spend of approximately BDT 40 crore/year. Pre-implementation process was almost entirely paper-based.
AS-IS (how it actually worked):
No system
No audit trail
Verbal rate comparison
Manual entry
Manual matching
Key gaps identified:
- G-001: No formal PO system → TO-BE requires Odoo Purchase module with PO number generation, supplier assignment, and email confirmation. Standard
- G-002: Approval via WhatsApp → TO-BE requires Odoo's purchase approval workflow with threshold-based routing (≤50k: direct approval; >50k: MD approval queue with email notification). Configuration
- G-003: No 3-way match → TO-BE requires Purchase-to-Inventory-to-Invoice matching (Odoo native, requires configuration). Standard
- G-004: No payment terms → TO-BE requires supplier payment terms defined on each vendor record. Standard
- G-005: Paper stock register → TO-BE: eliminated. Odoo Inventory replaces entirely. Business Change
Bicycle Manufacturer — Production Order Flow
A bicycle and cycle parts manufacturer exporting to Europe and the Middle East. Multi-level BOMs, component imports with LC, and a complex quality inspection regime.
Most complex AS-IS gap found: The production schedule was maintained in a large Excel workbook shared via Google Drive. The production manager updated it daily. Every department (Purchase, Store, Assembly, QC, Dispatch) maintained their own copy, leading to version conflicts and production stops when component availability data was stale.
TO-BE design: A single source of truth in Odoo Manufacturing. Material Requirements Planning (MRP) drives purchase orders automatically from confirmed production orders. All departments see live stock positions in Odoo. The Excel workbook is eliminated entirely.
Critical gap — multi-level BOM: The bicycle has assemblies within assemblies (frame sub-assembly, wheel sub-assembly, gear sub-assembly, final assembly). Odoo Manufacturing supports multi-level BOMs natively. The gap was not the software — it was the data. The existing BOMs had not been formally maintained for 3 years and contained obsolete components. The gap was a business change gap: the client needed to clean and validate all BOMs before go-live. This became a 6-week data migration workstream that had not been anticipated in the original project plan — precisely because the AS-IS phase had been rushed.
Trading Company — Multi-Warehouse Inventory
An importer and distributor of industrial goods with 3 warehouses across Dhaka and Chattogram. Inventory valuation disputes between the MD and Accounts were the primary driver of the ERP decision.
AS-IS finding: The root cause of the valuation disputes was discovered during the Gemba walk. Each warehouse was maintaining inventory in a separate Excel file at a different cost basis. Dhaka warehouse used last-purchase cost. Chattogram warehouse used average cost. The head office rolled them up manually once a month — with adjustments made "by judgment" when the numbers looked wrong. There was no single, consistent inventory valuation method in the company.
TO-BE decision: Enforce Average Cost (AVCO) valuation across all three warehouses in Odoo, configured as a single company with multiple warehouse locations. This was a business change gap — the decision required the MD to accept AVCO as the standard, which changed the reported gross margin on certain product lines. The gap analysis made this explicit. It was debated and resolved before configuration started, not during UAT.
In all three cases, the most valuable output of the AS-IS phase was not the process map — it was the question it forced. The RMG company had never asked whether WhatsApp approvals created an audit risk. The bicycle manufacturer had never asked who owned the BOM data. The trading company had never asked why their inventory valuation was inconsistent. A rigorous AS-IS phase surfaces questions that no demo, no RFP, and no vendor presentation will ever ask.
8 Mistakes That Derail AS-IS to TO-BE Mapping Projects
These are not hypothetical. Each one is drawn from a real implementation that ran into serious difficulty — some of which I was called in to rescue after the fact.
Interviewing only managers
Department heads describe the process as it should work. Floor operators describe it as it does work. When you only interview managers, your AS-IS map documents the intended process — which is often dramatically different from the actual one. The most valuable 20 minutes of any discovery session is spent with the person at the lowest level who touches the process daily.
Starting configuration before AS-IS sign-off
Vendor pressure to "show progress" leads to configuration starting while discovery is still underway. The result: the configuration team makes assumptions that contradict the AS-IS findings. Rework is expensive — a configuration built on wrong assumptions costs 3–5x the original effort to fix, because you are now fixing a running system rather than a blank one.
Designing TO-BE as "Odoo standard"
The TO-BE is presented as a walkthrough of Odoo's default workflows without any adaptation to the client's business. The client approves because they don't know what they're approving. Then UAT arrives and every tester says "this is not how we work." A TO-BE must be the client's process inside the ERP, not the ERP's process imposed on the client.
Skipping the exception paths
The standard process is easy to map. The exception paths are where implementations fail. What happens when a supplier delivers 80% of the order? What happens when the MD rejects a purchase approval at midnight before a critical production run? What happens when a customer returns half of a fully-invoiced order? Every exception is a test case waiting to fail during UAT. Map them in the AS-IS. Design them in the TO-BE.
No formal gap register
Gaps are discussed in meetings and noted verbally. The project proceeds. By UAT, nobody can agree on what was in scope. The client insists that a feature was promised; the consultant insists it was never scoped. Without a written, signed gap register, both parties are guessing. The gap register is the contract. It must be formal, written, and signed before configuration starts.
Treating every gap as a development requirement
Some consultants — especially those without strong Odoo configuration depth — default to custom development for gaps that could be solved with configuration or business change. Custom code is expensive to build, expensive to test, and most expensive of all to maintain across Odoo version upgrades. Every development gap should be challenged with the question: "Can we change the business process instead?"
No stakeholder sign-off at each phase
The AS-IS is completed but never formally approved. The TO-BE is designed but never formally validated. The gap analysis is shared but never signed. Without formal sign-off at each phase, every subsequent decision is contested. Get written approval (even email) at: AS-IS completion, TO-BE validation, and gap analysis freeze. These three sign-offs protect both sides.
Confusing data migration with process migration
The AS-IS mapping reveals process complexity. It also reveals data complexity — but they are not the same problem. Process migration (changing how people work) is addressed by the TO-BE design. Data migration (moving historical records into the new system) is a separate workstream with its own timeline, data owner, and quality gate. Conflating them in the gap analysis creates confusion about what is a process gap and what is a data gap. Track them separately.
Tools for Process Mapping
The tool matters less than the discipline. A well-facilitated session captured in Draw.io will produce better output than a poorly facilitated session captured in the most expensive enterprise process mapping software. That said, here are the tools I recommend and when to use each:
| Tool | Best For | Cost | Bangladesh Fit |
|---|---|---|---|
| Draw.io (diagrams.net) | BPMN process maps, AS-IS and TO-BE diagrams. Browser-based, no install, exports to PNG/PDF/XML. BPMN shape library built in. | Free | Excellent — no license cost, works on any browser, files sharable without tool access. |
| Lucidchart | BPMN and flowcharts with more polish. Better for client-facing deliverables where presentation quality matters. | $9–15/user/month | Good — but adds cost for the client team if they need to edit. |
| Microsoft Visio | Enterprise-grade process documentation. Full BPMN 2.0 support. Standard in larger corporates. | $5–15/user/month | Good for clients already in the Microsoft ecosystem. |
| Miro / FigJam | Collaborative workshop tools. Real-time co-editing. Ideal for the TO-BE design workshop where multiple people need to contribute simultaneously on a virtual whiteboard. | Free–$10/month | Good for remote workshops. Less ideal for formal BPMN output. |
| Microsoft Excel | The gap register. A well-structured Excel workbook with consistent columns and dropdown validation is more usable than many dedicated tools for this purpose. | M365 subscription | Excellent — universally understood, no learning curve, easy to share and filter. |
| Notion / Confluence | Living documentation of the gap analysis, decision log, and project assumptions. Best when the consultant and client are collaborating on the same platform. | Free–$8/user/month | Growing adoption in Dhaka corporate sector. Requires client buy-in. |
Connecting AS-IS/TO-BE to the Broader Implementation
Process mapping is not a standalone phase. It is the foundation that every subsequent project phase builds on. If the foundation is weak, every downstream phase is more expensive to execute:
Output: Configured system
Output: Migration plan
Output: UAT scripts
Output: Training plan
Output: Change plan
AS-IS to TO-BE process mapping is not a deliverable you produce to satisfy a project manager's checklist. It is the intellectual work of understanding a business and designing its future. Done well, it makes every phase that follows faster, cheaper, and more predictable. Done poorly — or skipped — it guarantees the most expensive kind of project failure: the kind that is discovered at go-live, in front of 200 waiting users. If you want to build this skill systematically, my Requirements Gathering course walks through discovery interviews and process mapping step by step. Need a BA to run this for your next ERP project? Let's talk →
Frequently asked questions
What is AS-IS process mapping?
AS-IS process mapping is the act of documenting exactly how a business operates today — including every manual step, workaround, exception, and unofficial approval. It is not an idealized description of the intended process. It is an honest capture of the actual process as performed by the people doing the work. The key distinction: managers describe the process they intend; operators describe the process they execute. A good AS-IS map reflects the operator's reality, verified and signed off by the manager.
What is TO-BE process mapping?
TO-BE process mapping designs how the business will operate after the ERP is implemented. It is not a description of how the ERP works by default. It is a blueprint of how your business will run inside the ERP, with waste eliminated, approvals streamlined, and integration points explicitly designed. The TO-BE is authored by the Business Analyst and process owners together — not delivered by the software vendor as a product demo.
How long does AS-IS to TO-BE process mapping take?
For a mid-size Bangladesh company with 5–8 departments, expect 3–5 weeks: 2 weeks for AS-IS discovery and validation, 1 week for TO-BE design workshops, and 1–2 weeks for gap analysis documentation and sign-off. For a larger or more complex company (15+ departments, multi-site, multiple entities), plan 6–10 weeks. Rushing this phase is the single most expensive shortcut in ERP implementation — every week saved in discovery typically costs 3–5 weeks in UAT rework.
What is a gap analysis in ERP implementation?
A gap analysis identifies every difference between your TO-BE process design and what the ERP can do natively. Each gap is then categorized — Standard, Configuration, Development, or Business Change — and a decision is made on how to close it: adapt the business process, build a workaround, or write custom code. The gap analysis directly produces the configuration scope, the development backlog, and the change management agenda. It is the document that turns a process design into a project plan.
Do I need BPMN to map processes? Can I use simple flowcharts?
You do not need to master BPMN to map processes effectively — a clear, consistent flowchart with swim lanes serves most purposes. However, BPMN notation is worth learning for two reasons: (1) it is internationally standardized, so any BA or configurator on the team can read it without a key; and (2) its specific symbols for gateways, events, and parallel flows capture nuance that generic flowcharts miss. The minimum set to learn: circles for start/end events, rectangles for tasks, diamonds for decisions/gateways, and horizontal swim lanes per role. That covers 90% of what you need on a real project.
What tools are used for process mapping?
Draw.io (diagrams.net) is the best starting point — it is free, browser-based, and has a full BPMN shape library. For workshops, Miro or FigJam allow real-time collaborative editing when multiple people need to contribute simultaneously. For the gap register, a well-structured Excel workbook remains the most universally accessible format. For documentation, Confluence or Notion work well if both sides are willing to adopt a shared platform. The tool is secondary to the discipline; a great map in Paint is more valuable than a mediocre map in Visio.
What is the biggest mistake in AS-IS to TO-BE process mapping?
The most consistently damaging mistake is interviewing only managers and not floor-level operators. Managers describe the process as it should work. Operators describe it as it does work. These two descriptions diverge significantly in every organization — and the gap between them is exactly where ERP implementations run into trouble during UAT. The second-biggest mistake is starting ERP configuration before the AS-IS is formally validated and the gap analysis is signed off. Both mistakes have the same consequence: expensive rework discovered too late in the project lifecycle.
When should I recommend custom development for a gap vs changing the business process?
Recommend custom development only when: (1) the requirement is genuinely non-negotiable — a regulatory compliance requirement, a contractual obligation, or a technical constraint with no workaround; and (2) no native configuration or creative workaround can meet the requirement adequately. Before recommending development, ask the client: "If you had to choose between changing this process to work with Odoo natively, or paying for development and maintenance of a custom module, which would you prefer?" Often, framing it as an ongoing cost changes the preference. Custom code should be treated as a liability on the project balance sheet — taken on only when the value unambiguously exceeds the long-term cost.