In this article, we will take a closer look at some of the questions from the previous blog. What exactly does migration entail, how often do you need to migrate, and what costs are involved in such a migration?
To learn what questions to ask and discuss and to understand and classify the answers, it does not only take a corresponding investment in time and effort on the part of the customer. The implementers also need to have the appropriate expertise in each of the relevant areas, but a single person cannot provide this.
Quite often, and motivated by Point 3 above, the next threshold is the construction of a prototype to ensure that both sides share the same understanding of the request. Still, this also takes time and is not even done by a programmer (see also our Blog on Odoo Studio).
However, this only concerns the initial analysis, but I am sure that you can well imagine that this consultation is a standard feature throughout the entire project.
The list of items and reasons to justify this step is seemingly endless. But does a project have to run like this? Is it not possible to merely use Odoo in standard mode?
The answers are short and simple – „you don’t have to“ and „it is.”
However, what are the prerequisites, what are the requirements and what are the risks?
It is hard to tell whether it is the fault of Odoo or the policy of the respective partner. Perhaps it is just one’s personal view on one’s own development or a reflection of what all the projects have in common when you take them over. Maybe it has to do with the fact that, when you receive them, some of the requests or specifications already contain precise functional descriptions. Or maybe it is only a question of a partner’s maturity once he gets involved.
We are quite familiar with this kind of approach from past experience. Quite often, decision-making bodies are present during the workshops, either discussing supposedly missing functions or planning processes and their optimization at the very beginning of an implementation. One of the reasons for these discussions is that the clients are familiar with the processes of the previous system that they regard as the “standard” and are now looking for a new and better “previous system” that covers the standard in the well-known way. Consequently, they now face a situation where implementations, if successful, are more than a little bumpy, consume a lot of support for „remedies“ and, in retrospect, are very difficult to scale.
 In a previous blog, we have already discussed our views regarding the definition of the term „standard“, what it is and what it is not.
The comparison may be valid or not, but it is a sad fact that people seem to compare Odoo and Microsoft Navision all the time. There is always at least one Navision partner in each bidding round of a tender.
In conversations, someone is bound to point out that „the other systems appear much more sophisticated when you look them in detail.” Much the same happens when we are processing or answering questionnaires or tenders that only inquire after a software’s features. Naturally, it is possible to replicate many of these functions, but they are simply not part of the Odoo Standard. The answer to the question of whether they are available, therefore, is a definite “no.”
Our recurring argument is that, in the long run, the software will be more cost-efficient and will offer more security since the Standard is the responsibility of the manufacturer. Thus, all risks of the implementation are already included in the license fee.
As everyone working with Odoo in daily routine can confirm, Odoo works very efficiently and reliably if the master data is well created and maintained assiduously. This is especially true for products and partners (designated either as customers or suppliers). Although products are significantly more complex to administrate, they are actually easier to manage, since according to the authorization concept only certain user groups are entitled to create and change products, the others are only allowed to read them. The situation is different for partners, as everyone involved needs to be able to create a new partner (usually a customer).