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…