The title is more or less the whole conclusion. I genuinely want to deliver good systems, exactly as it says. So let me set out my own thinking on this blog.
I want to do something worthwhile!
At university I majored in what would now be called data science. The phrase drummed into us at the time was "value creation". However sophisticated the analysis, if it does not feed a decision, no value has been created. Methods and techniques are only ever "tools"; unless they end up supporting some action and producing a meaningful result, they mean nothing.
The same goes for implementing an ERP system. Rather than being dazzled by which features exist and how far they can be customised, you have to work out what is genuinely valuable and approach it with business sense. With a system as flexibly customisable as Odoo especially, it is easy to fall into a state where anything at all is possible if you feel like it. Building a request exactly as stated certainly feels easier from the implementer's side, and it looks obliging. But whether it is actually valuable needs a cool head.
More customisation means more code to maintain. Which is to say it is generating future technical debt. I feel strongly that this is a fact both the user side and the vendor side ought to understand properly first. I try to hold on to that thought myself whenever I write customisation code.
I can't warm to designs that make life hard for users
Systems that push the burden onto the user put me off. The examples may not bear directly on ERP, but think of a credit-card signup screen where revolving credit is the default unless you change a setting, or a subscription service you can join in one click and then cancel only with great difficulty.
Among ERP vendors too, designs meant to lock you in genuinely do exist. You also come across responses that offer only an explanation designed to leave you feeling you have understood, steering your eyes away from the substance. I think approaches like these load the burden onto the user and do nothing whatever for building trust over the long run. I don't want to hand customers a system by way of an implementation like that.
How to avoid putting users in that position
So how do you avoid this bad state? First, by not drowning in the technology. You need to keep it in mind at all times that technology is only a tool, and never forget it. Getting a module you customised yourself working correctly is, admittedly, enormous fun. Once it is in, that part does become convenient. But at the same time it is always creating debt.
You must not answer everything a user wishes for exactly as asked. Work out the requirement sitting behind it, then put forward whichever of the many available approaches looks best at the time. That is how you get more value to the user. It is also why I sometimes check back persistently, and why we sometimes arrive at an entirely different answer in the end. But I think that is how it ought to go. (If anything, I believe this is where the value of consulting work lies.)
From a technical standpoint, using open-source software (OSS) is highly effective. Open source publishes its code to begin with, which is a large advantage in that it lets you avoid being locked in to a vendor. On customisation too, you get feedback from a worldwide community, so code quality naturally tends to rise. And at upgrade time the load is shared across the whole community, which makes it more efficient. Using the community's assets is, on any reading, the sensible thing to do. If you are using open-source software and yet not using the community's assets, that state of affairs deserves serious doubt. It plainly does not add up.
It is not that I am some "open source is the best!!" enthusiast, but on any reading it makes sense to use it, and I want to contribute to making it livelier.
In summary
In implementation and development, what I value above all is delivering value. Which means that rather than building a user's request as stated, it is important to identify the real problem behind it and choose the most suitable method. Sometimes that means proposing something other than what was asked for, but I think that is precisely the road to a sustainable, genuinely useful system.
Using open source is a very rational way to get there. It is transparent, the community keeps improving it, and it keeps your future flexibility intact. It is also an effective option for holding down the technical debt that excessive customisation brings.
I will keep working on building systems that deliver real value, and on contributing to the people who use them.
I want to deliver good systems