The crux of IT! – Or the question, why less is more!
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.
Option 1
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:
- A) These „full-service, all-inclusive packages“ are supposed to be able to cope with anything. As a consequence, the large number of features leads to a very high degree of dependencies, meaning in turn that it is impossible to change only one particular item, if a change is required. A small change usually triggers a whole chain of adjustments, leading to a higher budget, extending the project’s duration and increasing the risk of having to re-evaluate the entire set-up in a future version upgrade.
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.
- B) But does this necessarily mean that providers are not able to cope with rapid developments? Clearly, new versions also have to take into account every single component and integrate it into a new context. In fact, this may be one of the reasons why the technologies of established providers all seem to be a bit outdated. After all, who wants to take unnecessary risks by hazarding a new development?
- C) At the end of the day, we should not forget that complexity always comes at a price, especially in daily usage. It requires a high degree of continuous training, not only during a project’s implementation. And as one might expect, it is far from easy to correct erroneous entries in retrospective.
“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.
Option 2
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.
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!