One of the most important competitive differentiators of Siebel product is that, unlike our competitors, who limit what you can do, we let you customize almost anything you need to meet your particular business needs, and customers have taken advantage of that, such that their current implementation may not look a whole lot like the product we ship.

An on-going benefit of having chosen Siebel for your enterprise CRM platform is that we continue to release new features every month, evolving the product to keep pace with an evolving world, but unlike our competitors, such as SalesForce, we do not force our customers to upgrade on our schedule, but rather on theirs.

The dilemma our customers have always faced is, “How do I get these new features without overwriting my customizations?”, with more detailed questions of “How much time will it take?”, “How much of my work will I need to redo?”, “How do I know what to test?”, and many others promptly follow, and answering those questions required a healthy mixture of experience and guesswork.

No longer.

Thanks to a series of features released over the past several Monthly Updates, customers can now know what will change in a given release, allowing for better preparation and planning, as well as be confident that their customizations will be preserved.

RepositoryUpdate:  Keep Your Customizations

The first component is the introduction of RepositoryUpdate, which fundamentally changes how Oracle distributes Repository changes.  Historically—and this goes back to at least Siebel 98 when I showed up on the scene—when the Siebel development changed something in support of a new feature, we shipped entire object definitions, no matter how big the change.

Basic Example:  Consider the simple Account Screen, which had 99 associated Screen Views supporting all functionality for basic and industry use cases.  As a customer, perhaps you know you will only use ten of those, so you inactivate the other 89.  Oracle then adds a new Screen View—we would ship the entire Account Screen definition, which would include 99 active screens, reactivating the 89 Screen Views the customer had inactivated.

With RepositoryUpdate, we no longer do that—we ship only the specific change we made (in this case, a new Screen View definition for the Account Screen) and only that, so we do not touch the 89 Screen Views that the customer has inactivated.

This is a sea change, bringing the number of customer changes that were overwritten for a 17.0 to 26.5 update from over 10,000 to under ten, making adoption of features without overwriting customer changes incredibly efficient.

Monthly Update Pre-Assessment Report

In addition to the changing the way that Repository modifications are distributed, we now provide a Pre-Assessment Report, which is a lightweight way to determine in advance exactly what will change when importing the differences needed to support new Siebel features.  The key components of this report are:

  • It can be run in advance of the RepositoryUpdate itself to assess what would happen.
  • No changes are made to the customer Repository during its generation.
  • It provides details on the “Critical” changes—those where both the customer and Oracle have changed the same attribute on the same object—and “Informational” which simply show changes that Oracle’s development team has made, which are largely the additive changes.
  • Actual customer use, via Usage Pattern Tracking (UPT), Object Manager (OM) logs, and Siebel Test Automation scripts, are compared to the Repository changes made by Oracle to identify where testing efforts should be focused.

More Information

For more information, please leverage the following resources: