Introduction

An Odoo implementation should not begin with a list of apps to install.

It should begin with an understanding of how the business actually works.

A process discovery workshop creates that understanding before configuration, customization and development begin.

During the workshop, the implementation team works with business stakeholders to understand:

• How processes work today
• Where delays and manual work occur
• Which systems and spreadsheets are being used
• What controls are required
• Which decisions have already been made
• What needs to change in Odoo
• Which requirements still need clarification

This is important because the documented process is not always the actual process.

A company may say:

"Sales orders are approved before delivery."

But the real process may involve email approvals, spreadsheet checks, manager exceptions and manual communication with the warehouse.

A good discovery workshop uncovers those details.

The goal is not to document every activity indefinitely.

The goal is to create enough shared understanding to make sound implementation decisions.

Odoo Process Discovery Workshop: Quick Answer

An Odoo process discovery workshop is a structured session where business stakeholders and the Odoo implementation team examine current processes, identify problems and controls, define future-state requirements, and agree on the decisions needed for implementation.

A practical workshop should produce:

AS-IS process understanding

↓

Pain points and business requirements

↓

TO-BE process decisions

↓

Open issues and decision owners

↓

Implementation inputs and signed outputs

The workshop should therefore be treated as a decision-making activity, not simply a requirements meeting.

1. What Is an Odoo Process Discovery Workshop?

An Odoo process discovery workshop is a focused working session conducted before or during the early stages of an Odoo implementation.

It brings together the people who understand the business process and the people responsible for translating those processes into Odoo.

The workshop examines the current operating model and asks:

• What happens today?
• Who performs each step?
• What information is required?
• Which systems are involved?
• What approvals or controls exist?
• Where do problems occur?
• What should change?
• What should remain unchanged?
• What should Odoo handle?
• What requires integration, configuration or customization?

This creates a bridge between business requirements and Odoo solution design.

A discovery workshop can focus on one process, such as:

• Lead to opportunity
• Quote to order
• Order to cash
• Procure to pay
• Inventory replenishment
• Manufacturing
• Employee onboarding
• Expense management
• Financial close

Or it can cover an end-to-end business area.

2. Why Is Process Discovery Important Before Odoo Implementation?

Choosing Odoo applications without understanding the underlying processes can create problems later.

For example, a company may request:

"We need a custom approval screen."

But discovery may reveal that the real problem is not the screen.

The problem could be:

• Unclear approval ownership
• Missing approval thresholds
• Inconsistent business rules
• Manual email communication
• Lack of visibility
• Duplicate data entry

If the implementation team jumps directly into development, the project may solve the wrong problem.

Process discovery helps separate:

Business problem

from

Requested solution

This distinction is critical.

A good discovery process can also reduce unnecessary customization by identifying where standard Odoo functionality or configuration may already support the requirement.

3. Who Should Participate in an Odoo Process Discovery Workshop?

The workshop should include people who understand the process, make decisions about it, or will be affected by the future workflow.

The exact participants depend on the process.

Business Process Owner

The process owner explains the overall objective, policies, responsibilities and expected outcomes.

Functional Users

Users who perform the day-to-day activities provide practical details about how work actually happens.

Department Manager

Managers explain approvals, controls, exceptions, reporting requirements and operational priorities.

Finance Representative

Finance participation is important when the process affects:

• Accounting
• Invoicing
• Payments
• Tax
• Revenue recognition
• Costing
• Financial controls

Operations Representative

Operations users can explain real-world workflows involving inventory, procurement, manufacturing, logistics or service delivery.

IT or Technical Stakeholder

IT can provide information about:

• Existing systems
• Integrations
• Data sources
• Security
• Infrastructure
• Technical constraints

Odoo Functional Consultant

The consultant facilitates discovery, challenges assumptions and translates business requirements into potential Odoo approaches.

Project Sponsor

For important decisions, an executive sponsor may be needed to resolve conflicts and approve major process changes.

The key principle is:

Invite decision-makers and process owners, not only system users.

4. How Many Participants Should Attend?

A discovery workshop does not need a large audience.

Too many participants can make the session difficult to manage.

A practical core group may include:

For a focused workshop, 5–10 active participants is often easier to manage than a large group.

Additional subject-matter experts can join only for the processes relevant to them.

5. What Should Be Prepared Before the Workshop?

A productive workshop starts before the meeting.

The implementation team should understand enough about the business to ask useful questions.

Useful preparation may include:

• Business process documents
• Existing SOPs
• Organization structure
• Current application landscape
• Sample reports
• Sample transactions
• Approval matrices
• Spreadsheets
• Existing forms
• Existing dashboards
• Integration list
• User roles
• Compliance requirements

The team should also prepare a discovery question list.

For example:

Process

• What starts the process?
• What happens next?
• Who performs each step?
• What is the expected outcome?

Data

• What information is required?
• Where does it come from?
• Who owns it?
• Where is it stored?

Controls

• What requires approval?
• What prevents incorrect transactions?
• Which activities are restricted?

Exceptions

• What happens when something goes wrong?
• Are there manual workarounds?
• Who handles exceptions?

Reporting

• What information does management need?
• How frequently is it reviewed?
• Which reports are currently manual?

6. Odoo Process Discovery Workshop Agenda

A practical workshop can follow a structured agenda.

Part 1 - Business Context

Start by understanding why the process matters.

Discuss:

• Business objective
• Process scope
• Departments involved
• Current systems
• Major business constraints
• Expected Odoo outcome

The purpose is to establish context before discussing individual screens or features.

Part 2 - AS-IS Process Walkthrough

Ask stakeholders to explain the process from beginning to end.

Document:

Trigger → Activity → Decision → Approval → Output

Do not rely only on formal documentation.

Ask users:

"What actually happens when this occurs?"

This often reveals manual work and exceptions that are absent from official procedures.

Part 3 - AS-IS Evidence Review

Where possible, review real examples.

Useful evidence includes:

• Sample orders
• Purchase documents
• Invoices
• Reports
• Spreadsheets
• Approval emails
• Existing forms
• Screenshots
• Exported data

Evidence is particularly useful when different stakeholders describe the same process differently.

Instead of debating opinions, the team can examine the actual transaction.

Part 4 - Pain Point Identification

Once the current process is understood, identify the problems.

Typical pain points include:

• Manual data entry
• Duplicate work
• Delayed approvals
• Missing information
• Spreadsheet dependency
• Poor visibility
• Duplicate records
• Unclear ownership
• Reporting delays
• Reconciliation effort
• Lack of auditability

Do not immediately design a solution.

First document the problem.

Part 5 - Business Controls

Controls should be discussed explicitly.

Ask:

• Who can create the transaction?
• Who can approve it?
• What conditions require additional approval?
• Which fields must be mandatory?
• What should users be prevented from changing?
• What activities require an audit trail?

This prevents controls from becoming an afterthought during implementation.

Part 6 - TO-BE Process Discussion

Now move from:

How do we work today?

to:

How should we work after Odoo implementation?

The future process should not simply reproduce every existing manual step.

Ask:

• What should be automated?
• What should be standardized?
• What should be removed?
• What should remain manual?
• Where should approvals occur?
• Which system should own the data?

This is where the workshop becomes a transformation exercise rather than a documentation exercise.

Part 7 - Odoo Solution Direction

Only after the process is understood should the team discuss the likely Odoo approach.

A requirement may be handled through:

Standard Odoo

or

Configuration

or

Odoo Studio

or

Custom development

or

Integration

or

Process change

This distinction is important because not every business requirement should result in custom development.

Part 8 - Open Issues and Decisions

Not every question will be resolved during the workshop.

Instead of forcing a decision, record the issue.

For each open item, capture:

• Issue
• Business impact
• Options
• Owner
• Required decision
• Target decision date

This creates accountability after the workshop.

Part 9 - Recap and Sign-Off

End the workshop with a summary of:

• Agreed AS-IS understanding
• Agreed TO-BE direction
• Key pain points
• Important controls
• Open issues
• Decisions made
• Next actions

Stakeholders should have an opportunity to confirm whether the documented understanding accurately represents the business.

7. AS-IS Process: What Should You Document?

The AS-IS process describes the current operating model.

A useful AS-IS document should capture more than a flowchart.

Consider documenting:

This creates evidence that can later support solution design.

8. How to Identify Real Pain Points

Stakeholders may describe symptoms rather than root causes.

For example:

"The sales process is slow."

That is not yet a useful requirement.

Ask:

Where is the delay?

Perhaps the answer is:

"Discount approvals are handled through email."

Then ask:

Why does email approval create a delay?

Perhaps:

"Managers cannot see pending approvals in one place."

Now the problem is clearer.

The potential requirement may be:

Centralized approval visibility with defined approval rules.

This is much more useful than simply writing:

"Create approval screen."

A good discovery workshop moves from:

Symptom → Root Cause → Business Requirement → Decision

9. Document Business Rules Separately

Business rules are often hidden inside conversations.

They should be captured explicitly.

Examples include:

• Orders above a certain value require approval
• Discounts above a threshold require manager approval
• Certain customers require credit checks
• Purchases above a limit require additional approval
• Specific products require quality inspection
• Certain transactions are restricted to authorized users

For each rule, capture:

Condition → Action → Responsible Role → Exception

This makes the rule easier to evaluate during Odoo configuration and testing.

10. Identify What Should Be Standardized

Process discovery should also identify inconsistent practices.

For example, two departments may follow different procedures for the same activity.

Ask:

• Is the difference genuinely required?
• Is it historical?
• Does it create additional complexity?
• Can one standardized process work?

Standardization can reduce:

• Training complexity
• Customization
• Reporting differences
• Support effort
• Process variation

The goal is not to eliminate every business-specific process.

The goal is to distinguish necessary differentiation from unnecessary variation.

11. Define the TO-BE Process

The TO-BE process describes how the business intends to operate with Odoo.

A good TO-BE discussion should answer:

What changes?

Which manual activities will be removed or automated?

What stays?

Which business practices remain important?

What becomes standardized?

Which variations should be consolidated?

What requires approval?

Which decisions need formal controls?

What does Odoo own?

Which processes should be managed directly in Odoo?

What remains external?

Which activities belong to another application?

The TO-BE process should be realistic.

It should consider:

Business value + Odoo capability + user adoption + cost + risk

12. How to Decide Between Configuration and Customization

This is one of the most important outcomes of process discovery.

When a requirement is identified, classify the likely approach.

Standard Odoo

Use standard functionality where it meets the business need.

Configuration

Adjust settings, workflows, access rights or existing functionality.

Odoo Studio

Use Studio for suitable low-code changes that are governed and maintainable.

Custom Development

Consider development when the business requirement cannot reasonably be handled through standard functionality or configuration.

Integration

Use integration when another system needs to exchange data with Odoo.

Process Change

Sometimes the best solution is to change the process instead of changing the software.

This avoids the common mistake of assuming:

Requirement = Customization

13. Capture Integration Requirements During Discovery

Integration requirements should not be discovered after implementation starts.

Ask:

• Which external systems are involved?
• Which system owns the data?
• What information moves between systems?
• How frequently should synchronization occur?
• Is real-time communication required?
• What happens when synchronization fails?
• Who owns the integration?

Create an initial integration map such as:

eCommerce

↓

Integration Layer

↓

Odoo

↓

Accounting / Reporting

The exact technical architecture can be finalized later, but the business dependency should be identified during discovery.

14. Identify Data and Reporting Requirements

Process discovery should also capture the information users need to operate and manage the business.

Ask:

• Which records are required?
• Which fields are mandatory?
• Which reports are business-critical?
• Which dashboards do managers use?
• Which data currently comes from spreadsheets?
• Which reports require manual consolidation?

For reporting requirements, document:

Metric → Source → Owner → Frequency → Decision Supported

This helps ensure the implementation focuses on business outcomes rather than simply reproducing existing reports.

15. Discuss Costs and Risks Before Finalizing Requirements

Not every requirement has the same implementation impact.

A simple classification can help:

These are not exact project estimates.

They are a way to prioritize discussion.

A requirement with high value and high complexity deserves more architectural attention than a small interface adjustment.

16. Create an Open Issues and Decision Log

One of the most valuable workshop outputs is a decision log.

A practical format is:

This prevents important decisions from disappearing into meeting notes.

It also gives project governance a clear record of who owns unresolved requirements.

17. What Are the Key Deliverables From an Odoo Discovery Workshop?

A workshop should produce tangible outputs.

Recommended deliverables include:

1. Process Scope

Clearly defined processes and boundaries.

2. AS-IS Process Map

Documented current workflow.

3. Pain Point Register

Problems, root causes and business impact.

4. Business Requirements

Structured requirements linked to business objectives.

5. Business Rules

Approval, validation and control requirements.

6. TO-BE Process

Agreed future-state workflow.

7. Solution Direction

Initial classification of standard, configuration, Studio, development or integration.

8. Integration Requirements

Systems, data ownership and synchronization needs.

9. Reporting Requirements

Required reports, metrics and dashboards.

10. Open Issue Register

Unresolved questions and assigned owners.

11. Decision Log

Confirmed business and solution decisions.

12. Action Plan

Next steps, responsibilities and deadlines.

13. Stakeholder Sign-Off

Confirmation that the documented process and decisions reflect the agreed understanding.

18. What Does a Good Workshop Deliverable Look Like?

A useful deliverable should be specific enough to support implementation.

For example, instead of:

"Sales approval is required."

Document:

Requirement: Sales orders above the approved threshold require manager approval.

Trigger: Order exceeds defined threshold.

Approver: Sales Manager.

Control: Order cannot proceed until approval is completed.

Exception: Authorized users may follow an approved exception process.

Reporting: Management requires visibility of pending approvals.

This provides much better implementation guidance.

19. Common Odoo Process Discovery Mistakes

Starting With Odoo Screens

Showing screens before understanding the business can cause users to design the process around the software.

Start with the business process.

Inviting Only Managers

Managers understand policies but may not know every operational workaround.

Include experienced users.

Documenting Only the Official Process

The official SOP may not represent actual daily operations.

Validate the process with real examples.

Treating Every Request as a Requirement

A requested feature may be a symptom of a deeper business problem.

Understand the underlying need first.

Ignoring Exceptions

The normal process is often easy to document.

The difficult cases usually reveal the real complexity.

Discussing Customization Too Early

Starting with development discussions can encourage unnecessary customization.

First evaluate standard functionality and process changes.

Leaving Decisions Unassigned

An unresolved issue without an owner is likely to become a project delay.

Assign every important open decision to someone.

Skipping Sign-Off

If stakeholders do not confirm the documented process, disagreements can return during configuration or testing.

20. How Long Should an Odoo Process Discovery Workshop Take?

There is no single duration that fits every implementation.

A small process may need only a few hours.

A complex cross-functional process may require multiple sessions.

For example:

Trying to cover every process in one meeting can reduce the quality of discovery.

It is usually better to conduct focused workshops by business process.

For example:

Workshop 1: Lead to Cash

Workshop 2: Procure to Pay

Workshop 3: Inventory and Logistics

Workshop 4: Finance

Workshop 5: Manufacturing

This also makes stakeholder participation more relevant.

21. How to Run the Workshop Efficiently

A facilitator should keep the discussion structured.

A useful sequence is:

Understand → Evidence → Pain Points → Controls → TO-BE → Solution Direction → Decisions

Avoid spending too much time debating technical implementation during the discovery stage.

When a discussion becomes highly technical, record it as an architecture question and return to the business process.

The workshop should answer:

What does the business need and why?

The solution design process can then determine:

How should Odoo deliver it?

22. Executive Checklist for Odoo Process Discovery

Before closing a discovery phase, confirm:

Business

• Process scope is defined
• Process owner is identified
• Business objectives are documented
• Key users have participated

AS-IS

• Current workflow is documented
• Real examples have been reviewed
• Systems and spreadsheets are identified
• Exceptions are documented
• Pain points are recorded

Controls

• Approval requirements are documented
• Roles and responsibilities are clear
• Required validations are identified
• Audit requirements are understood

TO-BE

• Future process is agreed
• Manual activities to remove are identified
• Standardization opportunities are identified
• Process ownership is clear

Solution

• Standard Odoo options have been considered
• Configuration requirements are identified
• Studio requirements are identified
• Customization requirements are justified
• Integration requirements are documented

Governance

• Open issues have owners
• Decisions are recorded
• Risks are documented
• Next actions are assigned
• Stakeholders have reviewed the outputs

Frequently Asked Questions

1. What is an Odoo process discovery workshop?

An Odoo process discovery workshop is a structured session used to understand current processes, identify pain points and controls, define future-state requirements and make implementation decisions.

2. Who should attend an Odoo process discovery workshop?

Process owners, key users, department managers, relevant finance or operations stakeholders, IT representatives, the Odoo consultant and, when needed, the project sponsor should participate.

3. What should be discussed during an Odoo discovery workshop?

The workshop should cover the AS-IS process, real business evidence, pain points, business rules, controls, TO-BE process, reporting, integrations, open issues and implementation decisions.

4. What are the main deliverables of an Odoo discovery workshop?

Typical deliverables include AS-IS and TO-BE process maps, pain point and requirement registers, business rules, solution direction, integration and reporting requirements, decision logs and an action plan.

5. Why is AS-IS process mapping important for Odoo implementation?

AS-IS mapping shows how the business actually operates, including manual work, exceptions, systems and controls that may not be visible in formal process documentation.

6. Should Odoo customization be discussed during process discovery?

Yes, but customization should not be assumed as the solution. Requirements should first be evaluated against standard Odoo functionality, configuration, Studio, process changes and integration options.

7. How should open issues from an Odoo workshop be managed?

Record each issue with its business impact, owner, required decision, target date and status so unresolved requirements do not become implementation delays.

8. How long should an Odoo process discovery workshop take?

The duration depends on process complexity. A focused process may take a few hours, while complex cross-functional processes may require a half-day, full-day or multiple workshops.

9. What is the difference between AS-IS and TO-BE process mapping?

AS-IS describes how the business operates today, while TO-BE defines the agreed future process that the Odoo implementation should support.

10. Why should stakeholders sign off on discovery outputs?

Sign-off confirms that stakeholders agree with the documented processes, requirements and decisions, reducing misunderstandings during configuration, development and testing.

Conclusion

An effective Odoo process discovery workshop is more than a requirements meeting.

It creates a structured path from:

Current Process

↓

Evidence

↓

Pain Points

↓

Business Controls

↓

Future Process

↓

Implementation Decisions

The most valuable workshop is not necessarily the one that produces the longest document.

It is the one that creates shared understanding and clear decisions.

Before configuration or development begins, stakeholders should know what the business needs to change, what should remain standard, which requirements need further analysis, and who owns unresolved decisions.

With the right participants, a structured agenda and clear deliverables, process discovery can provide a stronger foundation for Odoo implementation, governance, adoption and long-term scalability.

If your business is preparing for an Odoo rollout, a structured discovery workshop can help identify process gaps, clarify requirements and establish the right implementation direction before major configuration and development decisions are made.

Request an implementation readiness workshop