Global Vision

"The road to success is always under construction; it's a never-ending progress, not a target to be reached"

Copyright

The texts, texts' fragments and images presented on this blog are copyrighted to their authors and protected by European and International laws starting from the publishing date. The texts, fragments of texts, and images may not be reproduced without prior written agreement from the authors. Failure to obtain the approval for reproducing the texts, fragments of texts and images is punishable under the law of the European Community and international treaties.

Sunday, February 01, 2009

Asset-based ordering

As part of the Order Management module, Asset-based ordering needs to be activated separately, allowing customization of workflows and business services.
Asset-based ordering bases on a prior order by the customer, thus on the fact that the customer already owns (or uses) a product (service) provided by the company or a partner. A customer that has acquired telecommunications services, providing the organization with a phone line and a phone number, owns, from the provider’s perspective, a valuable Asset on which building on future activities (a key strategy CRM point is in fact maintaining existing customers, before acquiring new ones). The client could, for example, decide to request other phone numbers on the same line, or to split existing numbers on different lines.
Asset-based ordering leverages the order management process as it supports the creation and management of complex orders (containing complex pricing, combined billing types, combinations of services, multiple suppliers, etc.). In the example given above, the phone line could be the property of a partner (as the distributor in an Energy business scenario), while even the service could be provided by another one; nevertheless, the client receives one bill containing the information for the various services, as well as segmented prices based on consumption.
After the first negotiation and order with the client, the sales worker can generate an Asset directly from the order. Starting from this Asset, new quotes and orders can be generated, or changes can be done to existing quotes orders. If the client changes the initial order, changes can be accepted (based on company’s policies) and implemented. It is easier as well managing subscriptions as the Asset management allows suspending, discontinuing or resuming the service provided. If the client does not pay the bill, the provider can decide to act by suspending the service until the payment is realized, so resuming the existing service. A household might request the provider to interrupt the service over a period of time (when they go on vacation for 3 months they do not need the home phone). In this case the provider stops the service and resumes it again at the client’s request. Figure 1 shows a Crm-UP, UML compliant, description of the functional cases managed by Siebel Asset-based ordering module (the module is depicted as the blue cube, reconnecting the business scenario to technical aspects of the Siebel architecture – as a specific case study).

Figure 1. Asset-based ordering – overview use-cases model describing the main actions supported for a sales worker, interacting with the system.

The Assets owned by the customer are registered in a service profile, indicating the installed assets. It is easily accessed from the Account Screen, Installed Assets view, and allows the customization of specific automated workflows to reduce the amount of time to create quotes, orders and assets.
There are three scenarios for initiating Asset ordering. The client can ask for a revision of an existing order (not yet passed over the point of no return). In this case, after negotiating the quote and starting the order process, the client decides to change something (a product/service, or conditions of the order, etc.). Depending on the organizational policies, the order might still be changed, unless is has reached a point when the changing costs are too high (the point of no return for order execution).
A second scenario envisions the client as owner of an Asset, but wishing to modify it. It is the case, for example, of a telco company’s client that wants to change from one type of contract to another, because her/his needs have changed, so that less free minutes are required (a down-grade of contract).
The last scenario envisions the modification of the prior order by adding a new item. The client might want a new phone line and number to be added to the prior subscription. The basic conditions are not modified in this case, just new items are added and might have an impact on the general order (on the sum, etc.).

Figure 2. General flow of Asset-based ordering following three initialization scenarios.

The three scenarios have different evolutions, depicted in figure 2. When modifying an existing Asset, the Sales Worker has to start from the Assets screen and fill in the details as required. Afterwards it is possible to generate a new quote and transform it in an order (following internal processes) with the help of automated workflows (like automatic generation of Quote from Asset, and of Order from Quote). When adding a new item, the Sales Worker starts from the Quotes screen, creating the Quote and filing in its details. If the change regards an existing Order, following organizational policies, the Sales Worker accesses directly the Order and performs the modifications. The execution of the order and its monitoring is facilitated by the integration with back-office systems.
Businesses that combine products and services, such as Telecommunication and Energy industry, can take advantage of the facilities offered by Asset-based ordering, reducing client-service time and improving overall monitoring of customer and service.

Sunday, January 25, 2009

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.