Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« Task Of Avoiding Stock Outs- Task Management | Main | Improvised dimensions and hierarchy in OFSAA 5.1 »

Yes or No to Customization of Oracle Transportation Management?

Organizations contemplating on using IT as an enabler to manage their transportation usually have 2 options in front of them, buy an ERP like Oracle Transportation Management (OTM) or build a product in-house.  There is also a middle path; it's the path of buying and customizing. The question which comes then is whether it is advisable to buy a standard ERP, which claims to have the best processes from the industry and yet is a generic product, and then customize it. A yes or no to customization cannot be simply a "Yes" or a "No". I will try to start the debate here and discuss some critical points on Oracle Transportation Management customization.

It is generally seen that organizations are looking for customization in the following fields:

1. Functionality change in the product by changing the source code.

2. Change/modification in the workflow.

3. A modified GUI adhering to the organization standards.

4. Customized reports.

OTM has done a lot to improve at least points 2, 3 and 4. Let us take them one at a time.

Functionality change in the product by changing the source code: This would require an in-depth knowledge of the OTM source code and would require a huge effort. This will be costly and definitely not supported by Oracle. This should be done only in case of extreme need and when all other options have been exhausted.

Change/modification in the workflow: OTM provides a very flexible way of building up a workflow with most of the processes being highly configurable. It uses Agents, Milestones, and statuses to configure the workflow. Most of the workflow requirements of an organization can be easily configured with minimal customization.

A modified GUI adhering to the organization standards: OTM provides screen sets and manager layouts to change the screens of OTM. Fields can be hidden or made visible. Default values can be added to individual fields. The menus can be changed according to the user roles. And all this is configurable with no customization required. If a very specific change is required which cannot be configured then the OTM pages can be even customized with minimal effort. The skeleton pages are already provided while creating the manager layouts. The only thing to take care is that during any OTM upgrades the pages are maintained and restored. Apart from this even the colour themes and logos can be changed to suit the organizations needs. The look and feel of OTM can be changed very easily to suit the organizations needs with minimal customization.

Customized reports: OTM provides a host of seeded reports but often organizations have specific needs and would prefer having a different report. From OTM 6.0 xml publisher has been added as a part of the product. Any report built using xml publisher is absolutely compatible with OTM. The reports functionality has come a long way from just having html and pdf formats to a laundry list of formats in which the user can view the reports. Report generation does not require any separate server or database. Customized reports can be generated with very basic configuration changes in OTM.

Apart from these the users can have custom logs and tables in database which will help debug issues in OTM. Thus we see that although some amount of customization is required to meet the needs of the organization but most of them are configurable using the features of OTM.

Even after all this customization is required then the below points and many more have to be pondered upon before customization is chosen as an option. When would you say "Yes" to customization? Some points to consider are:

1. My organization is reluctant to change the way of doing things.

2. It would require a huge training effort for the organization to adapt to the new processes of the product.

3. My business processes are better, unique, and absolutely critical for my business to run and would require the product to be customized to make it happen.

4. I have money in my purse for customizing the product.

5. I have a very capable IT team which can build and maintain the customization.

6. I am sure that the future releases of the product will not contain the customization I am doing on the product.

When would I say "No" to customization? Again some points to consider are:

1. The processes built in the product look good and can be beneficial to my business.

2. I do not have the money to afford the customization.

3. My organization is flexible and can adapt to the new way of doing things.

4. Maintaining the customization will be difficult for me.

5. I am very much dependent on the product vendor for all the support.

6. The future releases might contain the functionality I am looking for.

All this and more should be properly debated before any decision is taken. Customizing a product is not a sin but it should be done only after proper discussion after considering all options.

Acknowledgement: Anirban Roy

Comments

Hi Anirban,

Good thoughts...As long as a product is capable to handle the generic business requirements of different domains, we always end up with very less customization. As we always map business to the product rather than the other way.

Just want to ask:
1) OTM is a small product which can solve only one of the function of business (Logistics), so we sould not call it as an ERP. An ERP is a product, which can be used for all business functions (Purchase, Sales, Manufacturing, HR, Finance etc.) on a single UI & DB. So can we call OTM as an ERP?

Hi Lakshman,
Thanks for your comment.
I believe ERP is actually a concept and not really a product. Several vendors provide tools to help an organization to plan it's various resources. Some vendors provide a single homogeneous product, some break it up into modules. So for example if you take OTM for transportation and some other best of breed products for the different functions then this entire gamut would be called the ERP tool(s) of the organization with OTM being a part of it.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles