Siebel BA: why adding too many fields everywhere in the application is not a good idea.

In the context of CRM applications analysis, it's usual to receive requirements from the business users asking to add some more information regarding business entities on some views and screens and, to some extent, this is normal.
Issues arise when this concept is brought to the extremes and the users would like to have detailed information about specific entities (e.g. Accounts - Customers) in completely extraneous business contexts.
Apart from the impact that such an approach can have on the performances of your application, it’s also a bad way to establish a good relationship between the users and their perception of the CRM software.
The lack of an analytical tool in an organization, in fact, should not force the design of the transactional software: what has been created to help sales people or agents to follow their CRM activities and store customer information, should not be deformed to permit data extraction for forecasting analysis or sales pipeline.

As this was not enough, there is an aspect that very few people realize, even among the development or business analysis team: the fact that the information you have brought on a total extraneous business context might not be as updated as the original one.
Let’s take an example:
Let’s presume that the Account information on a Sales application includes a hierarchy level, represented by a list of values.

The Opportunities represent potential revenue sources for your company and are so consequently associated to an Account, being this a customer or a prospect.
In the case this Account is a customer, than most probably your company has sold it some products, thanks to a happy finalization of some opportunity (by a good sales rep. :)).
Adapting a Siebel application, it’s possible to visualize all the opportunities that are associated to a specific product. In this way you are able to make a generic analysis of your products’ trend.

If you have followed until now, you understand that we are going exactly to the kind of requirements that try to extrapolate analysis views out of the transactional application. Anyway, until now, without additional requests, the deal is feasible, or at least it seems. In fact, there are potential drawbacks on offering such standpoints, because now it will be normal for the user to ask more and more information also on the Opportunities List Applet at the bottom of the view.
If, for example, you will have to put the name of the account at the opportunity level, it won’t be a problem, because this is a normal attribute of an opportunity and so the information will be stored at its level.

But if the user will also ask for additional Account level information (the appetite comes eating…), as the hierarchy level information we mentioned earlier, and you are going to satisfy such a requirement, then you will be responsible of fake analysis done by the organization (if the employees will base on such a view).
Why? Because any account information that is stored at the opportunity level (brought by joins from the S_ORG_EXT table) will be the picture that has been taken at the Opportunity creation moment and not the current one!
In this sense, it could happen that a user will look at the Products > Opportunities View and realize that the hierarchy information of an Account related to an opportunity is not the "real" one, or at least is not the same as shown at the Account view level. Most probably, since the creation of the opportunity, for some business reasons the hierarchy level information has been changed (probably the account has changed its position in an industry chain), but of course no one, neither the application itself, has updated this info at the opportunity level!
The fact is that you are currently on the Products screen and so all the business information is driven by this and you should expect to see updated data only in relation to Products or directly linked entities (in this case the Opportunities, visualized on the second applet in the view).
In fact, how could information be updated over 3 or more different levels, if not launching a query on all the main tables (included Accounts, in this case)? Could you imagine the performance downgrade on such an approach? Have you ever wondered why Siebel, since the 7.7 version, has quite completely eliminated the multiple child applets from the Standard Views?
Everything is technically possible, but for sure we should not expect updated information with such a design (basically using just 2 applets and so 1 link).
If this is not realized and properly understood, then some developer will try to correct this false defect in the application and the most incredible things could happen.
Next time, if you are required to do such tings, maybe it’s better to explain the user that is not a good idea and offering on the contrary the possibility of a drilldown on the name of the opportunity. By doing this, at least he/she will be able to follow the related information, properly updated. Ok, you won’t be able to see everything in one shot, but let’s leave the analysis to the proper Tools…

Siebel Marketing 8 vs. Siebel Marketing 7.7/7.8

Siebel 8.0 has brought many enhancements that impact older versions' functionalities. There are several changes for Marketing with variations to the concepts employed until now.
Modifications can be found for Campaign Management, Marketing Resource Management and Web Marketing.
This post focuses on the improvements regarding the Campaign Management and the differences with prior editions. The objective is offering a better understanding of the new functions and concepts. In this sense, we are planning a series of posts referencing the changes brought by Siebel 8.0 on the Marketing domain: if you are interested, keep visiting us for updates.

In older Siebel versions, we got familiar with Campaigns as being children of Stages, in their turn children of Marketing Programs. Segments and segment tree cells could be associated with the campaign. Moreover, when executing a campaign, multiple waves could be defined in order to ease up large volumes executions. Each campaign could have multiple Offers which were channel specific. Segment Trees were related with Stage, while Segment tree cells were related with campaigns. This structure is represented in the following diagram.

In Siebel 7.7 and 7.8, companies used to define objectives and plan budgets at a Marketing Program level. In a telecommunications company, decision makers can define a budget for a general win-back program, meant to gain customers that have churned in the past. This action is quite complex and can be split into several stages:

- allowing customers to come back without any supplementary fee;

- encouraging customers to return if they are not satisfied with current provider and terms; encouraging silver and gold customers to come back by offering them a 5% discount on certain services/ points / etc.;

- focusing on the gold customers that have changed provider and offering them a 10% discount reward for returning, etc.

Stages can also be temporal: if the customers connected in the first stage show interest to the offer but still do not decide to accept it, one can plan a second stage in which the customer is offered a 5% discount in order to come back. Moreover the stages can be recurrent, repeated twice a year in order to assure continuous customer win-back.
A campaign addresses specific customers and presents them a specific offer. It can have different offers and also the same offer can be linked with different campaigns. A first campaign, part of the first stage, can be implemented impacting all the customers that have left the company in the first month of the current year. The message for winning back the customers can be initially send via sms or email, based on the available contact details and customer stated preferences. A second campaign could address the same pool of customers, but the offer could be presented via phone (by the call center agents) and only for the customers that prefer this type of channel.

The just described organization of concepts determined some issues at application level such as:

- redundancy of campaigns for multi-channel offers – you had to construct different entities for transmitting the message across different channels;

- complex allocation of segments to offers as the relationship is mediated through campaigns and event through stages – there is no direct relationship between the offer and the entities receiving it, thus it is hard to track activities from a customer/prospect perspective;

- no relationship among across-channels activities for analysis purposes – as there is no link between offer and segment/lists, it is impossible to find out who received what especially if one is interested in an across channels overview;

- campaign history does not record which offer among several associated with the same campaign was actually presented.

Siebel 8.0 introduces a new structure of concepts and different semanthic relationships. Campaigns are now understood as single stage communication to a specific group of customers or prospects. They can be stand alone or part of a multistage program. Offers are no longer linked with the channel, but represent just a single proposition sent to the target, hoping in an answer. A new structural concept is introduced: Treatments and they are children of offers. Treatments are channel-specific instances of an offer and include the associated content (channel specific). For this refer to the following diagram.

If a telecommunications company would like to make a campaign for winning back churned gold customers, with the campaign carried on during winter time, it can define an offer of 10% discount for the returning customers, if for example they come back until the 15th of December. The messages to the customers can be sent via various channels andin fact it is possible to define treatments such as Email message, SMS message and Fax message.

This new structure simplifies the process and facilitates the extension of the (same) campaign over several channels through multiple treatments. It also reduces data entry by enabling multiple segments targeting. Analyses are easier to carry on across campaigns and channels.
Moreover, Siebel 8.0 assures streamlines order management and loyalty integration by linking offers to product promotions and loyalty promotions. All this is backed-up by a series of enhancements: UI changes, business process and workflow changes, and data model changes.
From an end-user perspective, the application is now richer: new Offers and Allocation screens have been added. The new Offers screen provides the cross-channel “Offer” entity, while the association of treatments and offers is realized in the Allocation screen. Within the same campaign, one can allocate several segments, internal lists or segment trees, to one or more treatments linked with the campaign.
The Program Flow Designer has also been updated to have Segment Trees as children of Campaign, since the allocation rules have changed and you need to define a relationship among these elements. In prior versions, segment trees were allocated to stages being valid across campaigns (if needed). Another new feature is represented by the possibility of relating more than one segment tree to the same campaign. In this way it is possible to optimize the performance by splitting larger trees into smaller ones.

The structure changes also impact the business process and workflow level. In fact, the campaign load process differs by populating campaign ID and treatment ID for each contact, in the past editions it only populated campaign ID. Moreover, for each contact-treatment relationship a row is created in Campaign History, thus better storing the interactions with the customer/prospect.
All messages are now sent in the same wave. Stage execution workflow process is still available if one wants to execute several campaigns concurrently.

From a Data Model perspective, there are new relationships introduced: offer – treatments (parent:child, 1:M), offers – product promotions (M:1), offers – loyalty promotions (M:1).
The business component Response has suffered modifications to better support inbound interactions – the user key has changed as the treatment ID is required, while campaign ID is optional.
Campaign history populates treatment ID also based on allocations.
Segment trees are now linked at campaign level, in contrast with stage. Also multiple segment trees are supported per campaign, nevertheless deduplication against each other is not yet available.
The Campaign entity is now direct child of the Program one, while stage is an optional attribute of a campaign.

What does all this mean for your future upgrade?
The upgrade logic has to follow a certain path starting from the structural changes employed. Offers created in versions prior to 8.0 are preserved and transformed in “Treatments” and a parent offer with same attributes is automatically created for each “new” treatment.
The campaign history registers the primary offer for campaign in S_CAMP_CON.
Segment and segment trees that have been allocated in Siebel 7.7 and 7.8 also suffer modifications. If a segment tree cell was associated to a campaign, during the upgrade process the segment tree is associated with the campaign. The segment tree cells are then associated to the primary treatment for the campaign.
At least, responses are not impacted by the new improvements.

At a first glance it seems that Oracle has improved the functionality presented in prior Siebel (7.7 and 7.8) editions. However, the change in relationships and structure of concepts can be cumbersome for the IT specialists used to Siebel Marketing, at least at the beginning.