CANIAS ERP is an enterprise resource planning system that ships its development platform inside the product. That is the structural characteristic which makes the most difference in an evaluation: customisation happens in the product's own environment, without a separate tool or an external layer. This article covers the product's layers, its module structure and the questions you should have answered in writing before deciding.
Who develops the product?
CANIAS ERP is developed by Industrial Application Software (IAS). In its own material the vendor refers to more than 35 years of experience in business management software; that is the vendor's statement, not data we measured. The vendor states the product is used in sectors such as automotive, packaging, electronics, healthcare, food, retail, machinery, defence, textiles, mining, agriculture, energy and metals.
Three layers: application, TROIA, iasDB
When evaluating the product, question the three layers separately. Most evaluations look only at the first and skip the second — the one that actually creates the difference.
- Application layer. The module groups where the functions live.
- TROIA development platform. The product's own development environment. A fourth-generation, object-oriented language; an integrated development environment, a compiler and an interpreter come together. The vendor states that its customers have access to source code.
- iasDB database. The vendor states it is ACID compliant and supports unstructured data types such as text, images, audio and video alongside structured data.
Module groups
CANIAS ERP functions are grouped into abbreviated module groups: CMN (common/master data), ENV (environment and system), ETR (e-transformation), FIM (finance), HRM (human resources), LOG (logistics), PRM (manufacturing) and STP (strategic planning). On the finance side the headings include accounting, fixed assets, cost management, cost centre accounting, standard costing, financial consolidation, statutory reporting and e-invoicing.
The point to watch is this: the existence of a module group does not mean every function in that group is in your licence package. Scope varies by package, and that distinction must be settled in writing before the contract.
Deployment model and platform
The vendor states that both cloud and on-premise deployment models are offered. On the iasDB side, support for Linux, UNIX, macOS, Solaris and Windows is stated. Support for multi-company and holding structures is among the characteristics stated on the TROIA side.
What usually decides the deployment model is tolerance for downtime: if production terminals or tills depend on the ERP, offline capability or a local copy is required. We cover that assessment in the ERP selection guide.
Where does it hold up?
There is no single right answer; the product's structure becomes more defensible under certain conditions:
- When the number of non-standard processes is high. Having the development platform ship with the product makes it possible to customise without moving to an external layer.
- When the manufacturing model is complex. The depth of the manufacturing module group should be measured through fit-gap; we describe how in the manufacturing ERP guide.
- When source code access is a requirement. The vendor refers to customer access to source code; its scope and conditions should be defined in the contract.
By contrast, in a business whose processes do not differ from common industry practice, the flexibility may not pay for itself. A narrower product then produces a lower total cost. We cover how to build the comparison on criteria rather than brands in alternatives in the ERP ecosystem.
Questions to have answered in writing
- Which module groups and which functions does our licence package cover?
- Is API and data access included in the licence? Is there a call or volume limit?
- On what terms is TROIA access provided? Where do we find developer capacity?
- By which method are our customisations preserved through version upgrades?
- How many live installations exist in our sector and at our scale?
- Is the team assigned to us named in the contract, and how many projects does it run at once?
Not all of these are product specific; the framework for assessing the consultancy is in how to choose an ERP consultancy.
Frequently asked questions
What does CANIAS ERP cost?
We publish no prices on this page. Because ERP cost varies with user count, module scope, number of integrations, migration scope and development needs, an unverified figure would mislead. The line items are in how to calculate ERP cost, and you can derive the weights for your own scope in the ERP investment and TCO pre-assessment tool.
Is source code access on its own enough?
It is not. The critical question is not "is there source code" but whether the change you need can be made by a supported method and survives upgrades. Without discipline, access alone produces no advantage.
Can we work on the CANIAS side without replacing our current ERP?
Yes. On an existing CANIAS installation, process analysis, integration, reporting, data model and performance improvement work can all be done; none of that requires changing the product.
Why do the module group abbreviations matter?
Scope arguments usually start at the abbreviation level and end at the function level. "We have FIM" does not mean every function in that group is in your licence. Asking for scope in writing at function level reduces post-contract surprises.