Overview
In 2014, Sasmar Pharmaceuticals faced an enterprise technology decision that would influence the next decade of its growth. The company was not looking for a small accounting application or a temporary operational tool. It needed an ERP foundation that could support an international pharmaceutical group as its companies, regions, processes and digital sales channels expanded.
SAP was among the enterprise platforms Sasmar evaluated. As outlined in the official Odoo Experience session, Choosing Odoo Over SAP: The 10-Year Transformation Journey of a Global Pharmaceutical Group, the company ultimately chose Odoo and began its journey with Odoo 7 across six companies. More than ten years later, the environment has grown to support 22 companies across Europe, Asia-Pacific, North America and Latin America. It also connects manufacturing, distribution, finance and a complex eCommerce landscape that includes more than 25 Shopify stores, Amazon and other sales channels.
This distinction matters: Sasmar did not migrate from SAP to Odoo. It evaluated SAP and other options before selecting Odoo. The story is therefore not an SAP replacement project. It is an enterprise ERP selection case study followed by a long-term Odoo transformation.
The journey also offers a more useful lesson than a generic platform comparison. Choosing Odoo over SAP was only the first decision. The lasting result came from continually adapting the ERP architecture, standardizing operations, managing integrations and upgrading the platform as the business evolved.
The ERP Decision Sasmar Faced in 2014
An ERP decision at the beginning of an international growth cycle is difficult because the company must evaluate both current requirements and an uncertain future. A system may fit the business at six companies but become restrictive at 12 or 22. A platform may handle finance well but create integration problems when manufacturing, distribution and eCommerce are added. A highly capable enterprise suite may also introduce more complexity than the organization can productively govern.
Sasmar’s decision therefore needed to go beyond a feature checklist. The company had to consider whether an ERP could become a common operational platform while remaining adaptable over time. The decision also needed to account for different legal entities, countries, currencies and business processes without forcing every future requirement into a rigid initial design.
SAP was a credible option because it is built for structured enterprise operations, global control and complex business environments. Evaluating it was reasonable for an international pharmaceutical group. However, ERP selection is not a contest to identify the platform with the longest feature list. The real question is which combination of capabilities, architecture, implementation model and ownership approach best fits the company.
Readers who need a platform-level assessment can review this Odoo and SAP enterprise comparison. The Sasmar story addresses a different question: what happens when an international group selects Odoo and develops it as a strategic platform for more than a decade?
The Business Requirements Behind the Evaluation
Sasmar needed an ERP capable of supporting connected operations rather than isolated departmental applications. As the group expanded, the platform would need to coordinate multiple companies and regions while keeping data usable across sales, purchasing, inventory, manufacturing, distribution, accounting and management reporting.
The pharmaceutical operating model added another layer. Manufacturing could involve internal processes as well as external vendors working with semi-finished and finished goods. Inventory movements needed to remain visible across this flow. Sales and purchasing activity had to connect with stock and financial transactions. Different companies needed controlled access to shared processes while maintaining their own accounting, currencies, taxation and operational responsibilities.
The requirements were not limited to back-office ERP. Digital commerce eventually became a major part of the architecture. Orders from more than 25 Shopify stores, Amazon and other channels needed to enter a controlled operational flow. Product information, inventory, fulfilment and financial data had to stay aligned across a large channel landscape.
These requirements point to four enterprise priorities:
A multi-company structure that could expand without creating separate operational islands
Connected workflows across commercial, supply-chain, manufacturing and financial functions
Enough flexibility to support pharmaceutical and company-specific processes
An architecture that could evolve through integrations and version upgrades
Why Sasmar Ultimately Selected Odoo
The confirmed case information establishes that Sasmar selected Odoo after evaluating SAP and other enterprise platforms. It does not establish that software cost was the main deciding factor. Cost should therefore not be used to simplify the story.
The stronger business interpretation is that Odoo offered a combination of integration, modularity and adaptability that matched Sasmar’s transformation path. The company could begin with an operational foundation and extend it as its organizational structure and channel landscape grew. Odoo’s modular architecture also made it possible to connect ERP functions without treating every new business requirement as a separate software procurement exercise.
Flexibility, however, should not be confused with unrestricted customization. Odoo can be configured and extended around company-specific workflows but each extension becomes part of the long-term architecture. The value comes from adapting the platform selectively while preserving a maintainable core.
For Sasmar, the decision proved important because the same ERP family remained part of the company’s operations across a decade of expansion. The platform moved through major Odoo generations while the business increased its company count and added new regions, functions and commerce channels. That continuity is stronger evidence of strategic fit than the initial selection alone.
Starting with Odoo 7 and Six Companies
Sasmar began its Odoo journey with Odoo 7 and six companies. This starting point matters because enterprise transformation rarely begins with the final operating model already defined. Early implementations must solve immediate business needs while leaving enough architectural room for growth.
At six companies, the implementation needed a consistent company structure, master-data model and access framework. Products, customers, vendors, warehouses, charts of accounts and approval responsibilities had to be organized so transactions could move through the system without losing company-level control.
A practical connected flow would begin with demand entering through sales. That demand would influence product availability, purchasing or manufacturing. Inventory transactions would record receipts, internal movement, production consumption and delivery. Customer invoices and vendor bills would then carry the financial effect into accounting. Management reporting would draw from the same underlying operational records.
This connected transaction model is what allows ERP to become infrastructure rather than a collection of screens. When the company count increases, the same model can be extended with additional legal entities, currencies, warehouses, teams and rules. When the initial model is inconsistent, every new company magnifies the inconsistency.
Scaling from Six to 22 Companies Across Four Regions
Sasmar now operates 22 companies across Europe, Asia-Pacific, North America and Latin America. This is not simply a larger version of the original implementation. Multi-company growth changes the nature of ERP governance.
Every additional company can introduce local taxation, currency, accounting, commercial and reporting requirements. Users may work in one entity or across several. Products and business partners may be shared in some contexts and controlled in others. Intercompany transactions must be traceable. Management needs a consolidated view without removing the operational detail required by local teams.
The objective is therefore not to make every company identical. It is to establish a common operating model for processes that should be consistent while allowing governed localization where legal or commercial requirements differ.
In Odoo, that approach depends on disciplined company configuration, access rights, fiscal localization, intercompany rules, shared-data policies and reporting structures. It also requires decisions about which workflows belong to the global template and which may vary locally. The detailed architecture behind scaling Odoo across 22 companies is explored in the second article in this cluster.
Creating One Standardized Operating Model
A shared ERP creates value when it reduces process fragmentation. If every company uses different product structures, approval rules, order states and reporting definitions, placing them in one database does not automatically produce standardization.
The operating model must define how work moves through the group. A sales order should trigger predictable checks before fulfilment. Purchasing should follow common authorization thresholds. Manufacturing and external job work should use agreed stages and traceability rules. Inventory transactions should follow controlled routes. Financial postings should arise from verified operational events and use an approved account structure.
Standardization also needs ownership. Business leaders should own process definitions while the ERP team owns the integrity of the solution architecture. Local teams need a controlled method to request changes. Proposed customizations should be assessed for business value, cross-company impact, security, reporting consequences and future upgrade effort.
This is where enterprise Odoo differs from a small isolated implementation. The technology remains important but governance determines whether flexibility creates a competitive advantage or a growing maintenance burden.
Supporting Manufacturing, Distribution, Finance and eCommerce
Sasmar’s transformation demonstrates the importance of following the complete transaction flow. A pharmaceutical order does not stop in a CRM or sales module. It can create demand for finished goods, influence procurement and production, move inventory, trigger delivery and generate accounting entries. If external vendors perform part of the production process, semi-finished and finished goods must remain visible as responsibility changes.
The existing Sasmar pharmaceutical implementation covers these operational requirements in detail. Browseinfo’s implementation connected global operations, manufacturing, external job work, inventory, purchasing, sales, accounting, HR, approvals, eCommerce and reporting. The case study also documents the move from Odoo 8 to Odoo 16 as one major modernization stage.
At a process level, the connected flow can be understood as:
Customer or channel demand → sales order → availability and planning → purchasing or manufacturing → external job work where required → inventory and traceability → fulfilment → invoicing and accounting → management reporting
Digital commerce adds volume and integration dependencies to this flow. Orders from Shopify, Amazon and other channels need consistent customer, product, price, tax, stock and fulfilment logic. The ERP must receive and validate orders, allocate inventory, coordinate delivery and return the required status information to each channel. Financial results must remain reconcilable even when transactions originate outside Odoo.
Sasmar’s environment now supports more than 25 Shopify stores alongside Amazon and other channels. This makes integration governance a core ERP responsibility rather than a secondary technical concern.
Moving from Odoo 7 to Odoo 19 Enterprise
The journey from Odoo 7 to Odoo 19 Enterprise represents multiple generations of functional, technical and architectural change. It should not be viewed as one simple upgrade.
An enterprise version journey requires teams to evaluate custom modules, data structures, security rules, reports, integrations and business workflows at every major transition. Some custom functions may now exist in standard Odoo and should be retired. Other requirements may still justify custom development but need refactoring for the new framework. External APIs and channel connectors must be retested. Accounting, inventory valuation and open transactions require careful reconciliation.
The migration flow should therefore include discovery, code assessment, data preparation, target-version design, development, repeated migration testing, functional validation, performance testing, user acceptance and a controlled cutover. After go-live, reconciliation and stabilization continue until operational and financial results are trusted.
Sasmar’s existing case study documents a migration from Odoo 8 to Odoo 16. The official Odoo Experience talk positions the wider journey from Odoo 7 to Odoo 19 Enterprise.
What Worked During the Transformation
The most visible success was continuity through growth. Odoo remained part of Sasmar’s operating foundation as the group expanded from six to 22 companies and developed a much larger digital commerce landscape.
The unified model also connected functions that are frequently divided among separate systems. Manufacturing, external job work, inventory, purchasing, sales, finance, HR, approvals and reporting could contribute to one operational data flow. This supported better visibility than a landscape built around disconnected company databases and manual coordination.
The existing Sasmar case study reports measurable improvements including a 60% increase in operational efficiency, a 25% reduction in inventory costs, a 40% decrease in time to market and fully paperless HR processes. These results belong to the documented pharmaceutical implementation and should be understood in that specific context rather than treated as guaranteed outcomes for every Odoo project.
Another success was the ability to modernize in stages. Sasmar did not freeze its ERP at the version originally selected. The platform progressed through major upgrades as business requirements and Odoo itself evolved.
What Did Not Work and Where Caution Is Required
The official talk description states that the presentation will discuss what worked, what failed and what the team would approach differently. However, the published event page does not provide the full talk transcript. It would be inaccurate to attribute specific failures to Sasmar before those details are publicly documented or directly confirmed.
The case does reveal the areas where enterprise programs commonly face pressure. Legacy Odoo instances and disparate systems can fragment visibility. Manual approvals create delays and weak traceability. Company-by-company variations can undermine a global process model. Custom code and integrations can increase upgrade effort. A growing number of eCommerce channels can also turn order synchronization into a critical operational dependency.
These are not claims about undisclosed project failures. They are the implementation risks that an enterprise should examine when learning from the Sasmar journey. Once the complete talk or direct stakeholder input becomes available, this section should be updated with verified examples.
What Browseinfo Would Approach Differently Today
Based on more than a decade of platform evolution, Browseinfo would place even greater emphasis on governance at the beginning of a comparable program.
First, the global process template would be defined before extensive company-level customization. Each requested variation would be classified as a legal requirement, a genuine competitive process or a preference that should follow the standard model.
Second, custom development would be governed as a product portfolio. Every module would have an owner, business justification, dependency map, test coverage and upgrade plan. Standard Odoo functionality would be used wherever it can meet the requirement without weakening control.
Third, integration architecture would be designed for observability and recovery. Shopify, Amazon and other channel transactions would use consistent identifiers, queues, validation rules, error logs and reconciliation controls. A failed order or inventory update should be visible and safely reprocessed without duplication.
Fourth, upgrades would become a recurring capability rather than an occasional rescue project. Automated tests, documented configurations, clean repositories and regular removal of obsolete customizations would reduce the risk of future version transitions.
Finally, data governance would be treated as an operating responsibility. Product, customer, vendor and financial master data need clear ownership because no ERP architecture can compensate for uncontrolled data creation.
These principles form the basis of the cluster’s dedicated article on enterprise ERP governance.
When Odoo Is Suitable for a Global Enterprise
Odoo can be a strong enterprise option when the organization values an integrated and adaptable application environment. It is particularly relevant when the business wants to connect ERP, CRM, manufacturing, inventory, sales, services and digital commerce without building its operating model across many unrelated platforms.
It is also suitable when the company accepts that flexibility requires governance. A global Odoo deployment needs deliberate architecture, security, data ownership, testing, integration monitoring, performance planning and upgrade discipline. The question is not whether Odoo can technically add more companies or users. The question is whether the implementation model can preserve control as complexity increases.
Companies with strong process ownership and a clear distinction between global standards and local requirements are better positioned to scale Odoo successfully. The platform is also a practical candidate when phased transformation is important and the organization wants to expand capabilities over time.
When SAP May Remain the Better Fit
The Sasmar case should not be interpreted as evidence that Odoo is always better than SAP. SAP may remain the stronger fit for organizations that require deep global financial governance, highly specialized industry processes, sophisticated treasury, extensive group reporting or extremely complex production and supply-chain planning.
SAP may also be more appropriate when the organization already operates a mature SAP ecosystem and has the internal architecture, process and change-management capacity to support it. In those situations, moving to another ERP merely to simplify licensing may create more risk than value.
The selection should depend on operational fit, not brand size or a predetermined preference. Odoo offers integration, modularity and development flexibility. SAP offers enterprise depth, structured governance and a long-established global ecosystem. Both can be appropriate when aligned with the right requirements and delivery model.
Lessons for CEOs, CFOs, CIOs and ERP Leaders
For CEOs, the Sasmar journey shows that ERP should be evaluated as a long-term operating platform. The strategic value appears in how well it supports expansion, standardization and new business models over time.
For CFOs, connected operational and financial data is more important than isolated feature depth. Multi-company accounting, intercompany control, localization, reconciliation and management reporting must be designed together. Total cost should include implementation, integrations, internal resources, upgrades and governance rather than software licenses alone.
For CIOs, adaptability must be paired with architectural discipline. Customization, APIs, access rights, infrastructure and upgradeability are not separate technical concerns. Together they determine whether the ERP remains sustainable after ten years of change.
For operational leaders, process standardization cannot be delegated entirely to an implementation team. The business must decide which steps should be common across regions and where local variation is justified.
For ERP program leaders, the biggest lesson is to plan for evolution. Sasmar’s environment did not remain at Odoo 7 or six companies. The system had to absorb new entities, regions, processes, integrations and platform versions. A successful ERP design must make controlled change possible.
A Decade-Long ERP Decision, Not a One-Time Platform Choice
Sasmar’s decision to choose Odoo over SAP in 2014 was significant but it was only the beginning. The real transformation came through a decade of implementation, expansion, process connection, integration and modernization.
The group progressed from Odoo 7 to Odoo 19 Enterprise, from six companies to 22 and from a smaller operating footprint to four global regions. Its ERP environment now supports manufacturing, distribution, finance and a digital sales ecosystem involving more than 25 Shopify stores, Amazon and other channels.
That journey does not prove that every international company should select Odoo. It demonstrates that Odoo can become a global enterprise platform when the company’s requirements fit its architecture and the implementation is supported by disciplined governance.
For pharmaceutical organizations evaluating this direction, Browseinfo’s Odoo pharmaceutical ERP capabilities provide a starting point for assessing manufacturing, traceability, inventory, multi-company operations, finance and compliance workflows.
The best ERP decision is not the one that wins a generic comparison. It is the one that gives the organization a workable operating model today and a governed path for the next decade.
Frequently Asked Questions
1. Did Sasmar migrate from SAP to Odoo?
No. Sasmar evaluated SAP and other enterprise platforms but selected Odoo. The project was not an SAP-to-Odoo migration.
2. Why did Sasmar choose Odoo over SAP?
The confirmed public information states that Sasmar selected Odoo after evaluating SAP. It does not confirm one single deciding factor or state that cost was the primary reason. The decade-long journey indicates that Odoo’s integrated, modular and adaptable platform aligned with Sasmar’s evolving operating model.
3. How large did Sasmar’s Odoo environment become?
Sasmar’s journey began with Odoo 7 and six companies. The group now operates 22 companies across Europe, Asia-Pacific, North America and Latin America with Odoo supporting its wider enterprise environment.
4. Which Odoo versions has Sasmar used?
The overall transformation journey runs from Odoo 7 to Odoo 19 Enterprise. BrowseInfo’s existing implementation case study separately documents a major migration stage from Odoo 8 to Odoo 16.
5. Does Sasmar use Odoo with Shopify and Amazon?
Yes. The official Odoo Experience talk description states that the environment supports more than 25 Shopify stores, Amazon channels and other digital sales channels.
6. Can Odoo support a global pharmaceutical group?
Odoo can support multi-company and multi-country pharmaceutical operations when the platform is properly designed for manufacturing, job work, inventory, traceability, finance, security, localization, integrations and reporting. Suitability must be assessed against the organization’s exact compliance and operational requirements.
7. Is Odoo always a better enterprise ERP than SAP?
No. Odoo may be suitable when integration, flexibility and phased expansion are priorities. SAP may remain the better fit for organizations requiring deeper global finance, highly specialized industry functionality, complex supply-chain planning or a mature SAP-centered architecture.
8 What is the main lesson from Sasmar’s ERP transformation?
ERP selection is only the starting point. Long-term value depends on process standardization, data governance, integration control, maintainable customization, version upgrades and continuous alignment between the platform and the business.
