The starting point
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.
So what does all that entail? Let us have a look at the individual points:
“All-inclusive“ Pricing
It is true that, over the decades, the classic systems have been equipped with many small, sexy features here and there. Admittedly, it is very impressive to detect all the tiny details the software providers have taken into account. The many customer requests and feedback have left their mark – and let us not forget the several hundred programmers that had to be kept busy somehow.
Besides, the majority of features in the current versions already have reached a certain maturity, thus providing a certain guarantee that possible bugs have been fixed already.
It goes without saying that such a software has a considerable value and this value is reflected in the license fees. We are talking about quite a few hundred Euros per user and module.
You cannot have one without the other, or so it seems.
You cannot win a war with features alone
Let us take a closer look at all those features. I keep asking myself whether this plethora of functions – in addition to the decision for the right system – really does have any benefit. During all the years, I have spent in implementation and consulting, I have noticed several issues:
General
ERP systems are not specialized applications. Since such a solution is only effective if it integrates several areas of a company, each additional feature will result in even greater complexity. The transfer of information, already defined for various sectors, will create an increasing interdependency of the different elements, taking the complexity to the next level.
This takes us straight to the next point:
Training needs
A greater number of functions does entail a corresponding greater need for training. More fields, more buttons, more messages need to be understood and processed – and this kind of knowledge needs to be passed on.
Besides, new fields and functions create a completely new context and the user has to learn and comprehend them, so he/she can use them not only correctly but also efficiently.
Training may increase efficiency, but the greater complexity of the functions also leads to another issue that one usually tries to prevent:
More support
Interdependency and complexity inevitably lead to more incorrect entries, even if the user has had appropriate training. However, it is not the user who is to be blamed but rather a combination of reality and the user’s “appropriate assessment.” If everything were black or white, life would be simple. Nevertheless, it is often challenging to abstract a given case into correct field values or correlations within the system and to save the incident correctly in the application.
In the end, a support ticket is opened that needs to be processed.
Conclusions so far
As a result of the more extensive range of functions, the previous two issues will lead to continually increasing costs. We may even assume that most of these functions and their properties are either unknown or so specific that they do not bring benefit for the company and are therefore seldom used.
In doing so, we have noticed the following:
Consulting – the be-all and end-all
Another impression from the analyses of different tools we migrated to Odoo is that the implemented solution has a substantially smaller impact on a project’s success than might be assumed. The technical base should not be neglected, of course, but you cannot teach an old horse new tricks. After a certain point, any additional feature hardly makes any difference. The human factor within the project is much more critical. In other words, the know-how of the person implementing the solution, his/her ability to grasp the processes and the comprehension of the intended targets and, last but not least, his/her dedication to this process are essential.
In short, everything depends on how well and how comprehensively consulting has been provided.
This is the only way to build the user’s understanding and take care of our next issue:
The user’s fear of making mistakes
A high density of functions and a user surface possibly overloaded with icons may understandably cause concerns or at least respect.
For the users, this may be the smallest factor. After all, additional training goes a long way to mitigate these concerns. There are, however, changes in staff, more or less experience in connection with technical processes or commercial background. Since these systems solely depend on the users’ input for their calculations, these concerns are a factor that should not be neglected in the long run.
More features, less intuitiveness
What we can take away from the last paragraphs is that more features and, consequently, the increasing number of information within the individual surfaces do nothing to create the impression of an intuitive system. There are reasons for an increased training requirement, after all. The best example for that is the feedback from a new employee at a customer site who, to his astonishment, was able to complete an order after only two days of training. With his previous employer, he had needed a week of training and was not even sure whether he had recorded everything correctly while processing his first order.
However, this is just an isolated case. At the end of the day, this effect may also be achieved by the high individualization in Odoo. In itself, Odoo is no protection against this phenomenon.
Technical Background
Here are a few technical points that speak against a comprehensive range of function, and why less is more, after all.
Once in motion, it is hard to stop a tank
As described in the previous section, the goal of any ERP system is to create efficiency for the user. This may be achieved only by the transfer of information to downstream departments. These transfers represent interfaces in the system itself. The interfaces have to presuppose dependencies to be able to pass on information to the appropriate position in the subsequent process.
The risk begins whenever there are plans for adjustments within this ecosystem. If A and B are linked or interdependent, and A is migrated, B has to be migrated as well. If A is removed, what happens to B, which is expecting data? The technician needs to know about each individual item and to understand what kind of dependencies arise from each.
This is the exact point that explains why the budget for classic systems are not much lower even though they offer a comprehensive range of integrated features. The migration is considerably more complex and entails more of a risk.
Industry solutions may be even more problematic. The industry itself has already defined many specifications, but it is even more dangerous to individualize or re-build. After all, each company has its own living process, has grown in a different direction, when it comes down to detail, and, therefore, also works quite differently. This partly explains why most attempts at implementing an industry solution.
Conclusion
Even though we talk about digital units, in the end, they still form a mass that needs to be controlled. We may, therefore, conclude that re-building is far riskier than building.
This is precisely the Odoo principle. It forms a commercial base that makes rebuilding unnecessary. However, it provides the foundation of additional structures in the form of automatization, extra fields, additional calculations. These are then adapted exactly to the given requirements (at best even without any complex configurations).
The only remaining question is what does Migration entail? Are adjustments really problematic? You will find the answers in our next blog.
Was this article helpfull information to you?
Would you mind to leave us a review of your experiences with openfellas?
Talk to our experts.
We will find the solution best suited to you and your products!