Customer Relationship Management

Some of the key criterions, to be considered by an enterprise, which can help and influence the decision on whether to upgrade or re-implement the existing Siebel CRM applications include:

• Technical Upgrade Path:
In order to assess the complexity involved in upgrading to the latest product version, it is important to understand the version of the Siebel Application that is currently in use as that would determine the technical upgrade path to be taken.

Siebel 2000/6.x to 8.x:
Upgrading Siebel Application from an older version like 6.x to 8.x is a two step process i.e. upgrade from 6.x to 7.7 and then from 7.7 to 8.x. This can be a tedious process with significant changes to the User Interface, navigation, application configuration mechanisms, enriched functional capabilities, improved & flexible integration mechanisms, modified data model (party model in 7.x) etc. Re-Implementation can offer the flexibility to leverage the out-of-the-box User Interface layout, application configuration capabilities and out-of-the-box functional processes right from the start of the implementation. However, a significant data migration activity will have to be considered in order to design and migrate the data from the older version to the latest version. In most of these cases, the corresponding databases might also need to be upgraded to meet the system specifications and compatibility requirements with the latest version of the Siebel Application.

Siebel 7.x to 8.x:
Upgrading the Siebel Application from version 7.x to 8.x is a straight forward and single step process unlike upgrading from Siebel 6.x. Similarities to a considerable extent, in the application navigation, configuration mechanisms, and party data model philosophy help the upgrade and post upgrade processes easy to manage and execute. Siebel Upgrade can be a good choice in such a scenario. However, extent of existing customization and the additional functional capabilities to be built can swing the decision between upgrade and re-implementation approaches.

• Extent of Existing Customization:
As mentioned in the previous criteria, extent of customization in the existing version of the Siebel Application is very critical to assess the scope and effort required to leverage the out-of-the-box configuration capabilities from the latest version to be upgraded. Upgrade will result in migration of the existing configuration and customization to the newly upgraded instance. However, diligent feasibility analysis will have to be performed to understand the various options available to leverage the out-of-the-box configuration mechanisms and reduce the migrated customization to the extent possible. This can be a tedious process to accomplish if the existing instance is heavily customized. Lack of adequate documentation (which is the case usually ) can turn the entire de-customization process into a nightmare as the impact of this exercise on the existing functionality might not be assessed precisely.  If the extent of customization is simple-to-medium, then an upgrade option can be considered suitable. However, a heavily customized instance is not a very good candidate for upgrade and a Re-Implementation approach can be a better option.

• Cost of Upgrade / Re-Implementation & ROI:
The cost of upgrade versus the cost of re-implementation depends on various factors such as the version of the existing Siebel instance, complexity of existing customization, data volumes involved, extent of new capability that needs to be built, timelines involved etc. Though a technical upgrade can migrate the configuration and customization changes, it might need an additional diligent effort to modify the user interface layout, leverage out-of-the-box configuration capabilities to reduce customization and handle deprecated scripting methods etc. to make the upgraded instance functional and user ready. Upgrade offers great benefit in migrating the data, the configuration and the customization changes easily as compared to a re-implementation exercise where in the data needs to be migrated as a separate task and the configuration and customization changes built from the scratch. This will have impact on the timelines and the corresponding costs. Cost of upgrade can be less than the cost of re-implementation in cases where the complexity of customization is low and the version from which the upgrade is done is smooth such as Siebel 7.x and above.

• Risks Involved:
Each approach has related risks associated with them. An upgrade approach resulting in substantial de-customization effort might result in some functionality missing through the cracks, if the impact of the changes on the existing functionality is not assessed well. While in the re-implementation approach, non-availability of well documented business processes and requirements for the existing (old) functionality might result in some functionality missing through the design and build phases only to be caught during the validation phase of the program or sometimes even later !!!

There could be some more aspects to take into consideration to decide upon this dilemma, but I tried to share the ones that I felt are primary. Pls feel free to add in your thoughts as well to this.

In conclusion, there is no single pill solution to this dilemma and has to be considered holistically taking the above described criteria into consideration and fitting the same to each enterprise in conjunction with the enterprise’ risk appetite, future roadmap etc.