ERP customisation questions
When is a customisation actually justified?
When the process is one you genuinely win business on, and no supported setting covers it. A distribution rule that gets you a contract your competitors cannot service is worth building. A three-signature approval that exists because a manager in 2009 wanted it is not. The test we apply is simple: if this step disappeared tomorrow, would a customer notice, would a regulator notice, or would only habit notice. If the honest answer is habit, we will say so before we quote.
Will our customisations break when we upgrade?
It depends entirely on how they were built. Work done through supported extension points, custom fields, app-level modules, published APIs and documented hooks, usually survives an upgrade with a short regression test. Modifications to core files do not. They have to be reapplied, retested and often rewritten every release, because the vendor changed the code underneath them. A core modification made once becomes a cost line in every upgrade budget for the life of the system.
What does a typical customisation cost?
A small change such as a field, a print layout or a validation rule usually runs a few days including testing and documentation. A substantial custom module with its own data, screens, permissions and reports runs several weeks. A core modification carries the build cost plus a recurring retest and rework cost at every upgrade, which is why we quote those with the annual figure attached rather than the one-off figure alone.
Why do you push back on customisation requests?
Because most of them are cheaper to solve another way, and because we are the ones who will be maintaining the result. A large share of requests turn out to be report or dashboard requests, which cost a fraction of custom code. Others are resolved by a setting nobody had found. We work through the ladder with you first. A good customisation service will talk you out of most of what you ask for, and that is what you are paying for.
Will you maintain customisations somebody else wrote?
Usually yes, after a review. We read the code, check whether it sits on supported extension points or reaches into the core, and note what is undocumented or untested. Then we give you a written assessment with the annual cost of keeping each item. Sometimes the recommendation is to retire a customisation rather than adopt it, because nobody has used the feature in two years and it is still costing you money at every upgrade.
How do we tell a configuration from a customisation?
Configuration is anything you can change through supported settings in the application, by a person with the right permissions and no code. It is covered by the vendor, it is documented and it survives upgrades. Customisation is code, whether it sits in a custom app, a script or a core file. The practical difference is who carries the maintenance risk. Configuration leaves it with the vendor. Customisation moves it to you, permanently.
