Ultimately, there are probably only two basic approaches to implementing a software solution. In this context, it is irrelevant, whether we are dealing with an ERP system or something else, unless we are talking about an Office package, accounting software or any other out of the box solution.
– a virtual all-rounder, with a multitude of functions and synchronized features. Industry solutions and, of course, the software packages offered by well-known providers for CRM, ERP or eCommerce are prime examples for this variant. These solutions have grown over many years, on the drawing board and/or according to customer requirements. The presentations are most impressive. Before you have even finished your question, the cursor will start moving across the screen and screen shots will provide the answer.
A dream come true!
In view of this perfection, are there really any reasons to oppose this option?
An outright pro, of course, is that such a solution provides a feeling of security already during its presentation. Add the statement that every problem or issue may be resolved to 90% out of the standard software, and you get exactly what any customer wants to hear.
However, this immediately raises the question: if the manufacturer is responsible for providing „the standard“ and the customer for dealing with the adaptation, it seems obvious that the standard should cover as many functions as possible. Consequently, the total operating costs should be lower, shouldn’t they?
So, what prices are we talking about? The first question I ask myself, whenever the standard allegedly covers 90%: why then are the necessary budget not 90% lower as well? Licenses are, of course, an essential factor, but the price for the “configuration and consulting package” should actually be significantly lower, shouldn’t it?
In search for an answer to these questions, we now come to the heart of the matter:
Last but not least, it also means that there are only a few people who are actually able to assess the consequences involved in such a modification. Someone once told me that there are maybe 100 people in SAP who are able to do that. He himself had met only a lot of one-hundred-and-firsts.
“Be careful what you wish for, it might just come true.”
It is, of course, easy to say that this is exactly what you wanted. Strong dependencies virtually ensure high data quality. And if the system cannot come to you, then you will have to go to the system. After all, the goal is to live a standardized process.
However, this is a statement by someone who has no idea of the consequences such a wish may have! Anyone with a few years experience in IT knows that the dream of perfect data quality may quickly turn into a nightmare. If we look at it from a commercial point of view, where in this perfect world do we find the individuality that is an essential component of a company’s USP (Unique Selling Point)? If IT is the great leveler, where is the difference or the differentiation?
From a purely technical point of view, there is one other major disadvantage. Because it is quite problematic that even though a computer may be able to calculate really fast, it is only able to do so in exactly the order it has been given. If one has to deviate from this order, or even omit one or two steps, because they do not make any sense, one can only hope that there is a configuration somewhere capable of resolving this. Otherwise, we’re back to square one.
Finally, let’s not forget the previous blog article: looked at it from above or outside, everything may look the same or at least similar. There are many questions that have not been answered prior to the implementation, since there was no computer to provide calculations. Thus, we do not have any comprehensive answers.
– the approach of having only what is absolutely necessary from a commercial point of view. This is something that MUST be the same across the board, since anything else would be at odds with every business or entrepreneurial rule. Everything else, such as the separation of procedures by giving each process a separate status, additional fields, calculations, buttons and elaboration of existing formulas, in other words, the creation of the individual tailored suit, is part of the implementation.
Since this requires much more effort, what then are the pros and cons?
A major disadvantage is, of course, that the risk to decide in favor of an implementation is quite high, after all, the customer hasn’t seen much, if anything as yet. Since such a decision is usually taken commercially, not technically, it seems risky, and nobody wants to put his/her job at stake. This risk is quite valid and will linger, undoubtedly and unequivocally.
In addition, it seems logical that the effort now will be a big one, and the effort for introducing future versions will be just as great. Consequently, the project’s duration now will be very long and the total operating costs will be correspondingly high.
Interestingly enough, this is not the case. Since there are fewer dependencies within the system, fewer dependencies have to be taken into account. Moreover, at the moment everything is based on current and new technologies and, particularly, on a core that has been kept up-to-date. In other words, the required adjustments may be implemented comparatively quickly and easily. As a consequence, project periods are actually shorter and budgets lower. According to the Open Source motto “make it small, but make it efficient”, Odoo as a provider is capable of developing rapidly. This becomes obvious, if you google TinyERP 4.2, OpenERP 6.0or Odoo 11and compare the screens displayed. Whereas one had to work with a bulky, local client six years ago, a year later there was already a webfront end. Four years ago, there was only a webfront and for the past three years we have a new responsive and intuitive webfront end. Four years ago, only small and medium-sized companies considered Odoo as a solution, today the customer base also includes authorities and corporations.
So, what are the actual cons?
One actual con are the many questions that are asked during an introduction, since, as I already mentioned, the software only allows a certain tolerance taken into account at the very beginning. It is not sufficient to say, something is green, you have to describe exactly, which kind of green. Of course, this is also true to a certain extent for Option 1, but only to define the configuration or to protect the implementer. For Odoo, it takes a whole session just for definitions.
Another disadvantage, of course, is – make no mistake about it – the resulting dependence on the person or company who will set up the system, on his/their knowledge and expertise. If something goes wrong, all adjustment may be in your own hands, but a number of questions have to be asked and answered anew.
However, the following applies to both options:
The essential factor for the long-term design and implementation of a stable and upgradeable system lies in the understanding of all processes and in the ability to align them correctly with the existing components.
In the 3rd part of this blog series, I will go into further details and show, which building blocks are necessary for a project. In addition, I will define the general trend during implementation and where the actual cost drivers are.
Odoo Performance 
Diese Website verwendet Cookies, um Ihnen den bestmöglichen Service bieten zu können. Mit dem Besuch dieser Website erklären Sie sich damit einverstanden.
OK
Website verlassen