About Oracle CRM On Demand and Analytics

Some days ago I have been challenged in relation to the problems a company is facing in the management of their Siebel Oracle CRM On Demand system, above basing on the intrinsic technical limits of such a solution in the Analytics field, in comparison with the classic on premises solution.
It is a matter of fact that the Software as a Service model is finally spreading and taking the ownership of some previosuly unreachable market niches; the help, in my opinion, has arrived from the economic crisis.
Anyway since 2006, when I was called to bring on a functional comparison between the Siebel PRM solution and Salesforce.com, I have been really interested in the on demand concept and it's approach to business. I believe moreover that the web 2.0 technology can overcome many of the initial development limits of on demand applications; But it's true, there are still some limitations, above all when we talk about Analytics (they are technical for the cusomer, but I don't feel them as a technology limitation, but more as a specific marketing strategy - usually who buys such solutions does not want to be involved in complex cutomizations and so their development is not economically advantegeous).
Starting from a strong knowledge of Siebel Analytics (on physical, business, presentation/Answers layers and also ETL), in 2007 I have attended also the Siebel CRM On Demand courses from Oracle to get the solutions peculiarities, basing also on my consultancy background with the most famous on-demand application: Salesforce.com.
Based on this I have helped some partners in delivering tailored reports on an off-shore model, helping them understanding the gap between an on-premises solution and an on-demand one.
The Siebel CRM On Demand Data Warehouse is updated nightly so the reports always reflect quite recent information, but for sure not the one that “today” has been inserted by the company users in the OLTP, Transactional database. Moreover you are restricted to the Analytics subject areas to report on information that is refreshed daily.
Basically where is the limit in comparison with a “standard” version? We can individuate 2 parts:
1> the ETL part is fundamentally an Oracle responsibility, so you cannot bring data that is out of Siebel. Only Siebel OLTP fields will be mapped to the OLAP by Oracle.
2> You cannot create new star or snowflakes schemas, so you have to rely on the OLAP structure that Oracle maintains. Basically no new Facts or Dimensions: you can only add additional information but based on the existing relationships.
The advantages are performance and complexity wise , as no ETL is necessary on the client side.

Once you use your On Demand solution you have to be very carefull on the difference between the Reporting and te analytics sections.
Understanding the difference between an OLAP and an OLTP is fundamental: these DBs are not only different for the data that is inside (at maximum the OLAP is updated to the last upload of information from the OLTP or other connected transactional or even analytical databases) but for the schema structure itself. The first one is in fact optimized to establish relations between objects that are apparently (at least from a transactional standpoint) separate, but that need to construct the knowledge you want to highlight in a report/dashboard: from this the grouping in Fact tables, containing the information you want to measure, and the Dimension ones, containing the data that is used to calculate the facts (usually organized in Star schemas or Snowflakes).
Siebel CRM on demand clearly structure this concept in Analytics subject areas and Reporting sections (from Create New Analysis window): the last ones have to be used to report on information that is currently in the database (OLTP). Usually is used for simple list-type reports. For more complex reports you have to refer to the Analytics part where, changing the columns’ order, for example, you can group reports’ data based on the first column information (e.g. Sales Stage).
At least, it's always possible to do a little bit more direclty observing the resulting SQL query from the created report and adapting it to your needs.