A key part of our strategy at TIA – and one of the things which I believe differentiates TIA from many competitors is the uniqueness of a standard solution which can be used across many geographies. The reason for this is of course the ability to customize TIA, but just as important the level of localization of the product to fit local requirements.
Localizing a product as TIA, which is targeted at business processes is much more than merely translating the software. In fact, this is just the beginning. For a vertical solution targeting the insurance business, it is a key requirement that it fits well with local standards. This includes support of common interfaces, legislation, practices etc.
In order for TIA to handle this, the solution has from the beginning been architected in such a way that it is possible to create and maintain what is called “country layers”. A country layer is a collection of features supporting the requirements in a certain country or region.
The creation and design of a country layer is not a trivial exercise. It requires deep knowledge about the local practices combined with a solid insight into TIA. We are currently expanding our work in terms of building and supporting a number of country layers. This work is being carried out by TIA and selected partners providing local knowledge and product development skills.
Another aspect is specifically how these local features are developed and implemented. There are different strategies you can apply when doing this. One strategy, which we see happening with many competitors, is the development of local features in a one-off exercise with individual customers as an integral part of the customer implementation. By doing this, the customer will typically end up with a legacy product where the implemented code is not generic. There are many concerns about this method like no re-use, no portability of the code and low upgrade possibility of the standard solution.The right approach is to build a country layer in a generic way to be used for all customers in a certain country/region. This key to this is local functionality being coordinated and built into the standard solution. This in effect means that the standard solution eventually will include local functionality for all supported countries/regions - and it will enable the use of different local features across several countries/regions within one implementation. Only by having this approach you ensure re-use and eventually a lower cost and upgradeability. This approach is what we apply at TIA.
