The answer to the customisation question is not "can it be done" but "what happens at the upgrade". In CANIAS ERP, development happens on the TROIA platform that ships with the product. That flexibility is a real advantage; whether it turns into one depends on how the customisation is made and how it is documented. This article covers that discipline.
What is TROIA?
By the vendor's description, TROIA is a fourth-generation, object-oriented programming language; an integrated development environment, a compiler and an interpreter are supplied together. The vendor further states that customers can access source code, that recompilation is not needed during development, and that existing applications can be edited without restarting the system. A debugger and monitoring tools are part of the platform.
In practice this means you do not have to stand up a separate development stack for screen, report and business rule customisation. That reduces the technical setup load in a project.
The cross structure: customising without changing the standard object
The customisation approach the vendor describes rests on a customer-specific class being usable in place of a standard class. Why the distinction matters:
- The standard object is not touched. When the vendor updates the standard object, the collision surface stays narrow.
- The customisation keeps its own identity. What changed can be seen by comparing against the standard.
- The set to retest at upgrade can be identified. Instead of "let us test everything", the list of touched objects defines the test scope.
The opposite of this approach is customisation that changes the standard object directly. It looks faster in the short term; it produces the most expensive line item at upgrade time.
The price of flexibility: customisation debt
A development platform that ships with the product makes "yes, it can be done" an easier answer. Every easier answer grows the scope a little. The picture we see most often is this: thirty customisations that looked small during the project become, three years later, the load that locks the upgrade.
That is why we take every development request back to the fit-gap table first: can this need be met by standard function, by configuration or by integration? If it cannot, development happens — but the method and its upgrade impact are documented. We describe how that split is built in the ERP selection guide.
What must be recorded for every customisation
- What changed? Screen, report, business rule or integration endpoint.
- Why did it change? The business need behind the request and the unit that raised it.
- Which standard object was touched? If none was, that is recorded too.
- What will be tested at upgrade? The name of the workflow the customisation belongs to.
- Who did it, and when? During a handover this single line saves a great deal of time.
These five lines are the one document whose value rises as the number of customisations grows. Without it, three years later nobody has the answer to "why is this screen like this".
Three numbers to measure before an upgrade
- The number of customised screens and reports. Shows the size of the scope.
- The number of customisations touching standard objects. Shows where risk concentrates.
- The number of workflows to retest after the upgrade. The number that sets the duration of the upgrade project.
If those three are not tracked, upgrade duration cannot be estimated; an upgrade that cannot be estimated gets deferred, and deferral grows the debt.
Handover
The second purpose of customisation discipline is team independence. When source code access, documentation and environment setup steps are defined in the contract, another team can take the project over. We list the headings those conditions should be written under in how to choose an ERP consultancy.
We cover the product's layer structure and module groups in what is CANIAS ERP.
Frequently asked questions
Is staying standard always better than customising?
No. In processes that create real value and carry competitive advantage, customisation is necessary. The problem is not customisation itself but customisation that is undocumented and whose impact is unknown.
How often should upgrades happen?
Frequency is set by the product's release calendar and your own risk tolerance together. What matters is that upgrades are not deferred and accumulated: on an installation two versions behind, the upgrade reaches the size of a separate project.
Who should do the customisations: the internal team or the consultancy?
Either can; what is critical is that the method is the same. Developing a key user who can change reports and screens in-house lowers consultancy cost in later years.
Does source code access make upgrades harder?
Access itself does not. What makes it harder is using that access to change standard objects directly. A customisation made by a supported method stays portable regardless of access.