Parameter Decision in Odoo Part 1

Essential Parameters Impacting Your System Decision

Choosing the right ERP system is a far-reaching decision. Whoever has to make this decision should know what exactly they are deciding on. In this document, we would like to point out some of the parameters we consider relevant to the decision-making process. We also want to show how the proper selection process can or, rather, should work.



How should the selection process look like?

There are two approaches to the selection process, a large and a small tender, however you want to describe this process in technical terms. Essentially, it is the same for both.

What are the steps included in the selection?

No matter how extensive the selection process for a suitable solution, no matter whether it is about an ERP or another IT solution, these are the steps you should always follow:

• Needs assessment
• RfI (Request for Information)
• RfQ (Request for Quotation)
• Testimonials
• Cost-benefit analysis
• PoC (Proof of Concept / Feasibility)
• Prototyping

Even if there is a dependency between the individual points, there is no predetermined order to the list.

Needs assessment

Before you start choosing an IT solution, it is essential to understand your organization‘s exact requirements and needs and to go through a thorough needs assessment. Again, there are different approaches: You can document the various work processes as exemplary workstations (key users) or use cases or present them in multiple ways as a functional requirements catalog. However, a few rough key points can also define a minimum viable product (MVP).

We recommend a structured list – divided into one to three priorities – where the potential supplier may indicate fulfillment/non-fulfillment and leave comments.

It is also quite usual to provide the suppliers with a list of rough application points that may be used as an agenda during individual presentations.

RfI (Request for Information) (optional)

In this step, basic information is collected from potential suppliers.

The tendering company will send an inquiry as a structured questionnaire to find out more about the available solutions, technologies, and services to make this information more comparable.

Note: At this point in the process, removing some suppliers from the process should already be possible, thus qualifying the pool.

RfP (Request for Proposal)

Once the selection has been narrowed down to a shortlist of suppliers, an RfP will be issued. This is a formal process where suppliers are asked to provide detailed proposals for the solution as well as a cost calculation for the catalog of requirements. It is essential to provide more framework parameters for the proposal (number of employees, number of users and clients, currencies, list of existing solutions, etc.).

Note: After this step, you should create a shortlist with two to three suppliers, as the following steps will involve significantly higher personnel costs on the customer side. Focusing on a minimal group is essential to keep costs lower and the timeline shorter.

Testimonials and Case Studies

Validating testimonials and case studies from suppliers provide insights into their previous projects and successes. This helps to assess the supplier’s and their solution’s quality and reliability.

Cost-Benefit Analysis

A comprehensive assessment of the costs compared to the expected benefits is crucial. This includes acquisition costs, running costs, maintenance costs, and potential savings.

Proof of Concept (PoC) – Feasibility Study

We recommend running a feasibility study to understand each supplier’s or implementation partner’s solution and knowledge. This involves implementing a miniature version of the IT solution to test its functionality in the real environment, allowing the identification of potential problems at an early stage and the assessment of the solution’s performance.

Usually, a workshop will be held with each potential partner where the rough functions and requirements are defined, and the current processes are presented to be tested after realization with the PoC. Alternatively, you can have the suppliers propose a solution concept, but whether this will actually work is left to trust. In terms of evaluation, a PoC is much more reliable.

Note: After this step, you should be able to decide in favor of one solution and one supplier.

Prototyping

It may make sense to go one step further in a particular area and create a prototype for very complex and extensive projects. This allows stakeholders to experience the solution’s functionality in detail and provide feedback before the final implementation.

Below, we will take a closer look at the characteristics and different scaling within the individual steps.

The large tender

The entire comprehensive tendering process is often outsourced to a specialized company taking over the requirement analysis and preparation of tender documents. Many tendering companies want the documents to be processed by experienced and qualified employees of the respective supplier. However, they often need to remember that the respective team cannot process very extensive questionnaires with several hundred to sometimes thousands of questions as it would go far beyond any reasonable scope.

As a supplier, you can recognize the differences between the accompanying partners by the questionnaire and its details. Is the catalog specific, inflated, or adapted to the company’s size, and have these steps been carefully thought through?

Regarding project size and costs, investing up to 20% of the project volume in a feasibility study is advisable. The result can then be developed into a prototype.

The small version

We also recommend this approach for small project sizes, where each step would be correspondingly smaller. Instead of a comprehensive questionnaire, it is sufficient to note the most essential requirements or critical parameters of the target solution:

• How many employees and users will the system have to accommodate?

• Is it a multi-client solution?

• In which sector and customer structure does the company operate (B2B or B2C)?

• Are there different branch offices, and in which countries?

• How many currencies will be required?

• What is the approximate range of expected functions (CRM, Sales, Purchase, Inventory, MRP, Accounting, etc.)?

• Are there any specific requirements that must be met?

• What are the most significant implementation risks from the customer’s point of view?

With this information, any implementation partner can get a good idea of a potential project and even tailor the sales presentations to your needs and expectations.

The steps regarding the request for quotations and testimonials should, of course, be covered as well.

The PoC is a decisive step. We strongly recommend that this be performed – even on a small scale. Limiting the prototype to a core process or function is advisable to make the effort manageable. It is usually sufficient to show the current system and method to the potential partner, provide some critical data, and then have them show you the counterpart in Odoo. You may invest half a day’s or even a full day’s work, but afterward, you will have a good idea of the system and the potential partner’s way of thinking and finding solutions.

Everything else, including prototyping, may be transferred to the actual project.

What are the most important criteria for selecting an ERP system?

We recommend opting for a generalized system rather than an industry solution. The main reason is that a generalized system fits a broader user base. This, in turn, positively affects the process flow, the support available, the supplier’s economic stability, and technical development. It also reduces system disruptions, the need to change applications, and required interfaces.

Independence

The aim of every company should be to minimize dependency, which should also apply to the choice of IT solutions. The selection process can lead to two kinds of dependencies: dependence on the software manufacturer and dependence on the implementation partner. In the long term, both may be risky and often go together. If the manufacturer imposes a dependency due to their licensing model, becoming independent of the partner during or after implementation is challenging.

Open-source systems not only offer independence from the manufacturer but many other advantages in the project, as, for example, the manufacturer’s involvement is not excluded per se, and all subsequent adaptations are also available in the source code. What does this mean for the customer? The customer benefits from the manufacturer's further software development, the implementation partner’s expertise, and, when applicable, from the partner’s specific customizations.

Partner structure

In addition to the customer base, the manufacturer’s partner structure should be an essential aspect of your decision. By partner structure, we mean that the manufacturer provides an extensive and international catalog classifying partners according to their level of experience. This guarantees independence from the implementation partner (keyword „partner change“). A broad and international partner structure is essential for the roll-out or the company’s growth. There is also simply more leeway in the selection process, as partners may be able to offer different service profiles and/or specializations.

Scalability

Ensure the ERP system is scalable to keep up with your organization’s growth. It should be able to support additional users, modules, functions, clients, currencies, and languages. In a multi-client environment, not every client offers the same business portfolio or has the same processes, so the system should be broadly based and flexible in its configuration per client.

Modularity

Keep it small and simple – a guiding principle of IT with many implications.

The more functions a system offers, the more complex it becomes. As a consequence, significantly more factors must be considered during implementation, perhaps even elements that may seem irrelevant at the outset or never become relevant.

To limit the complexity, effort, and risk to what is actually essential for the implementation, a system should have a modular structure so that only the modules pertinent to fulfilling the core requirements are included in the initial implementation.

After the initial implementation, additional areas or functions can be added at any time (see the previous paragraph on scalability).

Integration

Check how well the ERP system can be integrated with other existing systems in your organization. Seamless integration is crucial to ensure data consistency and a smooth information flow. The „jack of all trades“ rarely exists in IT, only if the respective industry requires few software systems. The production area alone requires integrating production machines, which often have their own protocols, or exchanging correspondingly complex parts lists. An ERP system’s main task is to feed the quotation system with data for calculating margins or to make a delivery date transparent. It should transfer orders for fulfillment and support a planning and control level to monitor margins, and it should help determine requirements passed on to the purchasing department. Finally, it should offer automated invoicing, accounting, and all the possibilities of cost control and company transparency through extensive reporting options.

Even if Odoo offers many more possibilities, everything else is not part of an ERP system’s core task.

Therefore, integration capability should be considered an important priority.

User-friendliness

User-friendliness is a decisive factor in ensuring that employees can use the ERP system effectively, that it is fun to work with, and that the onboarding process is quicker and easier. An intuitive, memorable, and, above all, straightforward user interface is critical here. Of course, training is a topic that should be addressed, and sufficient documentation and videos should be available.

Adaptability

A good ERP system should be adaptable to meet a company’s requirements. This may include customizing screens, data models, activities, workflows, reports, or dashboards.

Future viability

Ensure that the ERP system is at the cutting edge of technology and can support future developments in the industry to guarantee long-term investment security.

Costs

Consider not only the acquisition costs but also the long-term operating costs, implementation costs, and maintenance fees. A comprehensive understanding of the total cost of ownership (TCO) is essential.

Which of these points are covered by Odoo?

To answer this question, let’s take a detailed look at the individual aspects and compare them to Odoo’s offer.

Independence

Below is a brief overview of the various factors that ensure independence:

Open-Source

With regard to open-source, Odoo will probably always be one step ahead, as it is currently the only and largest generalized open-source ERP system with an international approach. The source code of the Community Edition is published under the GPL, the Enterprise Version under the MIT license, which is also open-source. In other words, each customer can access the entire system’s source code.

Since all alternative systems are closed-source, a comparison does not make sense.

Distribution

Odoo has been enjoying rapidly increasing popularity for many years. With currently over 7 million users it is certainly not a tiny upstart. Quite the contrary, it is firmly established in all sectors, all company sizes, and most countries worldwide.

In addition, it has an enormous and very active community, e.g., in the translation of new features, the number of forums and their active members, the creation of video material in well-known channels such as YouTube, and the creation of blog articles, websites, instructions, FAQs, hints, posts, etc.

In short, there is enough visual, audio, and written material to find answers.

Partner structure

Here, too, the system is firmly established internationally. The partner structure is organized worldwide, and in almost every country, there is a good selection of potential partners, subdivided into a classification (partner level) that symbolically reflects the partner’s size and acquired expertise.

Scalability / Modularity

To summarize this aspect in one paragraph, Odoo is not a monolithic system; its core comprises individual modules. The system may be used in CRM, HR, accounting, purchasing, or anywhere else.

Another advantage is that customizations may be encapsulated as modules, making migration much easier. This also entails that you can increase the system’s complexity in individual steps. The system also supports the addition of several clients, currencies, and languages. Potential growth in width and depth is virtually limitless.

None of the sector’s market leaders offers this kind of flexibility. With most of them, the core remains as is. Additional modules may be purchased via a partner structure like proprietary systems, but they are not as flexible and scalable, let alone integrable, as in Odoo.

Integration

Since Odoo has a strong and flexible API, is able to export and import anything and everything at any point, and offers a framework that may be customized to any interface, there is no limit to the integration options. You could even say that it is entirely up to the counterpart whether docking is possible.

In this area, the well-known providers are less well-positioned. In many places, comprehensive access to data is only possible via database access since the system offers no export options.

When it comes to interfaces, competitors often offer REST APIs. However, an REST interface can only cover one function or process at a time. If you need more functions, you also need several REST Calls, making the software significantly less flexible by comparison.

User-friendliness

This subject is as challenging to treat objectively as the question „What is beautiful? “because it depends on what you know or expect, whether you prefer working on a laptop or using mobile devices; in other words, it depends on user habits. Ultimately, this leads to a highly subjective evaluation.

However, from experience, anyone working with Odoo will understand the user interface very quickly, as it is very tidy and offers many detailed functions for fast and efficient work. The process flow very much controls the display, and only a few buttons are shown on the screen. As the screens are always structured the same way and harmonized across the modules, the user can rapidly understand new elements and may familiarize himself with them quickly and efficiently whenever needed.

A small comment, even a little dig: The market leader with three letters hardly triggers a „Wow“ reaction regarding speed or an intuitive and straightforward interface.

Adaptability

Each module has its own extensive configuration to efficiently and flexibly define the complexity of processes for the requirements of different industries and company sizes. For each module, the scope of configuration options may be determined via a settings page, allowing the system to react dynamically to further developments within the company and be customized without programming.

Should this be insufficient, individualizations or extensions can also be programmed. Odoo is very straightforward and customizable in all areas. Customizations can and should be encapsulated to avoid compromising the system’s core. The data model, masks, processes, etc., may be extended anytime.

Future viability

Odoo is based on a modern software stack, and the technology is always up-to-date, thanks to an annual release update. Odoo integrates new technologies with every new version; e.g., ChatGPT has been fully integrated with version Odoo 17.

Costs

The license costs are very low compared to other systems, especially if one uses Odoo as an integrated solution. If you add up the costs for a CRM solution, ERP, accounting, and HR solution, you quickly reach amounts of several hundred Euros per user and year.

In addition, there are monthly hosting costs. However, they are much cheaper than similar systems since Odoo is not a resource-gobbling application.

The implementation and support costs certainly account for the largest share of the total costs. Here, too, there are significant differences within the partner landscape. Even if an hour of consulting is significantly more expensive than an hour of development, the consulting approach has the advantage that it guarantees a more efficient and cost-effective system implementation through the associated change management in the long run.

Another critical factor in the implementation’s success is the integration and understanding of accounting. Understanding the accounting evaluation of individual transactions is the key to recognizing and specifying a stable implementation of the respective requirements. Still, since accounting is automated in many places through integration, the greatest efficiency and transparency gains are to be found in this area.

User rights vs. Community

The license model is the critical difference between Odoo and „classic“ systems. Even if licenses need to be paid in Odoo, they are linked to the maintenance contract and the Enterprise package. An Enterprise contract may be canceled or not extended if a customer no longer sees any added value. However, this voids the warranty, i.e., Odoo is no longer obliged to fix programming errors free of charge, and the database migration has to be performed by the customer (but there are several alternatives, even though they may not be as convenient as a migration). The Enterprise module must be removed from the server.

However, you can still use the system itself and all its customizations!

This contrasts with the classic license model of closed systems (such as SAP and Navision), where only user rights are acquired. Consequently, no further access is possible if these rights are no longer paid for.

Migration and data

Thanks to agile approaches in software development, IT systems develop much faster today than ten years ago. Therefore, the question of updates has become a crucial issue when making a decision. It is not for nothing that Microsoft Windows, for example, has switched to a so-called „rolling release“ that no longer recognizes versions. Incidentally, this is a methodology from the open-source world.

However, new versions not only have a problem with conversions in the front end, but data must be migrated. The easiest way to do it is, of course, to have your solution operated by a manufacturer via a cloud, thus simply delegating the problem, including data.

Relinquishing the sovereignty over your data, together with the exclusive acquisition of user rights, is a particularly unfortunate combination since it results in total dependence on the system supplier.

Odoo’s counter-model is an in-house operation, whether on your hardware or in your cloud (the maintenance of which we will be happy to take over).

The offer to migrate your data as part of the maintenance contract is unrivaled and unbeatable.

Until now, we have always talked about a “migration project,“ a wording that suggests the effort and timeframe involved.

Source code – security and a guarantee for the future

Apart from the very opaque license models of many manufacturers and the patent situation, there is another crucial reason why open-source has become internationally successful in recent years – the source code delivered with the installation. This is not about transparency, though, but about two aspects that make it possible:

1) Independence

Since the source code becomes available with the installation, you are independent of the supplier. As long as software is not a niche product but a widely accepted solution (such as Odoo), other knowledge carriers can provide support and perform customizations. There are more than 1,200 certified Odoo partners worldwide.

2) Guarantee for the future

Since the source code is available not only for customizations but also for the entire system, the community of platform users also becomes independent of the manufacturer. If developments emerge that are no longer accepted by the community or if the manufacturers get into financial difficulties, the project may continue under a different name as a so-called Fork.

Modularity

The core of many classic systems is still monolithic. This is not surprising as ERP solutions are based on a complex data model, and functions have to be harmonized. Therefore, these systems cannot simply be modularized into individual parts – we have already addressed this issue in two of our previous blogs:

The openfellas approach to implementation

What makes IT tick – or an answer to the question of why less is more

Odoo, on the other hand, has a modular structure from the outset, making it possible to introduce a jointly agreed basic implementation. Once the system is used efficiently and successfully, it may be rolled out further.

The fact that customizations can also be encapsulated as modules is another advantage. This makes migration easier and enables the increase in system complexity in individual steps.

Module width vs. functional depth

Within a company, it is often challenging to draw a clear line and determine that one area depends on the information and the other area(s) only on the amount of data, and there is no need for an exchange between the two. This is not possible since, at the end of the day, everything will end up in accounting, either as revenue or costs. A line must (or will) be drawn here.

The advantage of a fully integrated system is that the data can be transferred from module to module, and there is no double entry. However, a system must first create a basis for complete integration.

If you look at the variety of modules within Odoo, it is pretty clear: if not Odoo, then what else?

The price you have to pay is that many small functions created in some classic systems cannot exist.

a) since it is impossible within a modular system, where the set of installed extensions may be numerous, and it is almost impossible to harmonize all features and

b) it contradicts the minimalist approach

The trick, after all, is to introduce a system so successfully that every intended employee is a user working with it and to design processes that run significantly more efficiently and error-free. Pure common sense will tell you this can only be realized with a “less is more“ approach because functions and automation are easier to add than remove or rebuild.

Localization and accounting

Accounting in Odoo is GoBD-compliant and can be fully utilized in Germany despite the pending certification. Incidentally, certification does not protect against incorrect use or absolve management of their responsibility.

There is a localization of each European country, which installs the usual taxes and accounts charts but also adapts the general financial reports to the minimum legal requirements. Additional functions are also installed, e.g., in the case of Italy, the transmission of invoices via EDI.

Odoo supports multi-currency operations. However, its core functions lie in accounting. The functions for full support are:

• Exchange rates between currencies may be maintained manually but can also be automatically reconciled with the ECB daily, monthly, or annually.
• One main currency can be defined per client.
• In the posting record, a currency other than the client’s may be specified to interpret the posted amounts in this currency. In non-visible fields, the amounts are calculated in the client’s standard currency at the then valid exchange rate and stored at the time of posting.
• All statistics are based on the standard currency.  

Modules by openfellas

Over the past ten years, openfellas have developed a large number of modules that may be used in projects as a basis for implementing requirements or increasing process efficiency, as they are automations or background calculations that have proven their worth.

Examples include:

• EDI connections to suppliers

• EDI connections to logistics providers

• Extensions for mapping complex purchasing conditions

• Exchange Connector

• Datev Connector

• Shopware Connector

Odoo Gold Partner

For the past three years, Odoo has made the conditions for an Odoo Gold Partnership much stricter, causing a lot of movement in the partner landscape.

To achieve Odoo Gold Partner status, 300 new users must be registered annually. In addition, a retention rate of 80% has to be completed, i.e., 80% of customers or Enterprise users must be renewed each year.

Moreover, six permanent partner employees must be certified for the current version to maintain the categorization. During certification, the candidate is asked 80 random questions on all modules available in the Standard version. At least 70% of the questions must be answered correctly within a narrow timeframe.

The requirements are similar to those of SAP and Microsoft. This shows that Odoo also attaches importance to qualified consulting within the partner landscape to minimize risks of incorrect implementations and to maintain the image of a stable system.

review openfellas