In my last blog post, I harped on “Product localization concept”, covering aspects like definition of Product Localization, building baseline version for a product and implementation strategies across industries.
In this blog, I would like to talk on yet another key aspects that need further emphasis – Configuring local features.
Configuring Local Features: what is it and how do we get started?
Configuring local features – meaning a product should have a UI where in the local features are properly defined. But, what are the local features. Local features are subjected to industry / domain, statutory rules & regulations of the local body, operations in the organization, transaction recordings, transaction processing (computation logics), reports & data analytics. These are some of the few list which I could list down, however, a complete list is beyond the scope of this blog and better left to the experts of a particular segment. These should be further listed to fine grain & pick up entities that can be localized. In this blog, I would cover the below items
Customer master & Product masters (depending on the industry) would remain the same in any industry, however, the number of data capture source might vary from industry to industry & so on. The product should have the provision to customize i.e. have flexible data entry for this entity.
Operations in the organization – meant to first / users of the organization & not the end customer of the organization, what types of hierarchy your product would like to support, one to many, many to one, 2 level, 3 level or ..n level hierarchy availability?…Authorization based on the setup which would again vary by organizations, you need to provide the feature in the product where you can define based on the need of the organization, to what level of authorization can be provided would be a local definition
Transaction recording & processing – As I mentioned in the earlier blog that, baseline version plays a key role in leveraging for localization. This is very important part of the product, to what level does your product allow to configure this feature for local definition. Depending the need & factors mentioned above, one should have the feature in modifying the base line version either should be able to add / remove / modify the entities available.
Processing would require feature in the system on how the processing of the transaction should be done. The baseline version should have the provision where you can define on how the common logics can be defined and mapped to the transaction. This again an expert in the domain would be able to articulate to finest level & further can be designed.
Reports is one of the common modules where customer expects that you have a framework where in customers can extract the data based on the data storage. The framework has to be given to the customer with the data dictionary of the product, so that customer need not pay for reports that can be easily extracted from the framework. This does not mean it’s the end of road in this module for customization. Customer would still require reports which require your expert help to design & develop the report which becomes the customization & not localization!!!!!
I have covered the key areas of the localization of the product in 2 blogs. I thank you for reading my blog and look forward for your valuable comments.
