Readers of this post will note that they have probably found many many articles online with the same title. However, I want to approach this question from a business perspective instead of technical.
When SSI started to represent Odoo, it was critical that source code was included and we would be able to customize it to our customers needs. We have been in the business of ERP software for 40 years now, and there is one universal truth, Customers expect the software to match their business.
Technical Debt
Conversations around customization should start with the concept of Technical Debt. I've seen many different definitions of technical debt but the easiest way for me to explain it is that "if you wrote it, you own it."
When Odoo releases a new piece of functionality they are guaranteeing the user that they plan to support and maintain that functionality in each new release. The same cannot be said with custom code written just for your business. In the future, as things change that code may need to be adjusted or even re-written to be compatible with your system.
Define the problem statement
The first step is to get all involved parties in the same room and hash out what the real problem you are solving for is. Too many customization requests just start out with people saying "the system should...". I am positive that if all involved parties can put in writing their problem and agree on it that you will have a better experience.
A problem statement seeks to identify the root cause and need while not assigning blame or allowing for distraction. Encourage your team to reach deeper than surface level to make sure that the problem is the software, and not just a underperforming employee, external process, or other culprit. You should be able to define the problem so clearly that it can be written on paper and agreed upon by all involved parties.
Document the shortfall in your current configuration
Documenting the shortfall is an important step as well. Sometimes, when the problem is well enough explained to an Odoo expert it may be clear that further configuration out of the box can solve the problem. Remember that just because that's the way something has always worked doesn't mean that's the only way it can work. You may be surprised to find out that through additional configuration that Odoo can already meet your needs.
Provide your partner with screenshots or videos of you processing the transaction. I will be the first to admit that watching one of my customers use Odoo fascinates me. They often navigate to things differently than me, or pay attention to fields on the screen that I often gloss right over. Your partner is relying on you to explain the steps you take to replicate the problem statement.
Once you've decided to move forward with the customization, here are the steps I suggest you follow:
1. Provide Clear Direction
You want to give your partner the most detailed understanding of your requirements that you can. This may include a flowchart, or detailed business case that they can review and discuss with you in advance. Unclear requirements lead to re-work, cost overrun and frustration. Ideally the partner will share with you a detailed design schematic when they submit the estimate for the development
2. Mock it Up
Users of Odoo are usually familiar with the Odoo Studio module. A quality partner should be able to mock up the basic design of the new functionality in Studio before writing more code. This is not always true, as it just depends on the functionality you need built. However, a sketch of the end outcome is a good first step before doing too much work.
3. Partner Test
Write multiple test cases for your partner. Most partners are going to have their own test case ideas, but the reality is this should really be provided by the person commissioning the work. Nobody knows your business the way you do, so give the partner some specific testing scenarios to follow BEFORE they send it to you to test.
4. User / Customer Test
After the partner has completed their internal testing, they should provide you with a link to a staging environment for you to test the customization. Do not allow for the code to be installed in your live system until you or your designated users have tested it yourself.
5. Documentation
If your partner is unwilling or does not offer documentation services, you should take the time to write your own documentation on the customization. Even if it seems like a rudimentary change this information will be valuable in the future during the upgrade process. Just a few simple screenshots and copies of the test cases used during this process should be tucked away and saved for the version upgrade in the future. The same test cases should be used when upgrading the system.
Summary
This post is not a case for or against customizing Odoo. There is tremendous value in matching software exactly with your business process. Customization involves risk (much like every other decision you make in business).
When you decide to write a customization follow the steps above to ensure that your project is successful and can be migrated to versions in the future with as much ease as possible. Poorly documented customization's will cost more to upgrade and additional time will be spent on developing the test cases in the future if not done correctly the first time.
