Or take, for example, a situation where you have a number of competing delivery companies that can deliver an order to a customer. On the face of it, they’re all pretty much the same – each one claims it’ll get the delivery to the customer on time – and whilst they charge different amounts for their service, keeping our costs to a minimum isn’t always the most important thing, if we’re looking to build customer loyalty as well.

So, we’re in a situation where every company claims to do the same thing, but you know that in reality some will perform better than others in different situations. How do you make a decision on which delivery company to use then, when you’ve got competing business goals, a bunch of suppliers that perform differently in different situations, and you’ve got to make a decision when you don’t have perfect knowledge of all the factors?

This is where a tool like Real-Time Decisions comes in. Using Real-Time Decisions, we can set up a process that receives the order details, takes into account the context of the order (the day of week for example), factors in, for example, the fact that you want to in general offer better service to premium customers, and the builds up a model that records what actually happens, correlates this with the details of the order, and gradually builds up an model that can predict, given your business goals and the context, what the best delivery firm would be for a particular order.

So how do we set up Real-Time Decisions (RTD) to put this all in place? The first step is to start up Oracle RTD Studio, define a new Inline Service, and create an “entity” to hold the details of the order.

This entity will allow RTD to consider the city that the order is being delivered to, whether the customer is a premium customer or not (so that we can treat them slightly differently), what day of week the order is placed, the value of the order and the size of the package, in case these factors turn out to influence the outcome of the delivery. When a decision needs to be made, the calling application will contact RTD, pass across the order ID and these bits of information, and they’ll then be persisted in RTD until the decision process is complete.

The next thing we need to do is to create some inputs into the RTD decision process. These inputs are called “informants” and we create one for the start of each individual decision process, for when we pass across the details of the order, and for when the decision process completes. We also create another one, which we’ve called “Supplier Feedback”, that we let us pass feedback into the decision so we can tell whether the decision we made turned out to be the right one – this feedback loop is key to how RTD works and allows us to create a “self-learning model” that gets more accurate the more decisions it makes and feedback it receives.

Each one of these informants has input parameters, which in the case of the start and end informants is just the order ID, but in the case of the one that receives details of the order, consists of the list of order details that gets passed through from the calling application.

Each of these input variables is tied back to the session variables set up when the decision process started, so that’s available later on when a choice needs to be made.

Now that we’ve got some inputs into the decision process, it’s time to start setting out the choices that can be made. First of all is the list of delivery companies we can choose from, which we enumerate in the application under the heading of a “choice group”.

Each of these choices can have attributes assigned to them, such as an ID code, a description and so on.

We then do the same for the days of week, the size of packages and the cities we deliver to, with all of these choices and options being enumerated in the application so that we can assign outcomes and probabilities to them later on.

UPDATE : You don’t actually have to define choices and choice groups for these input variables, you only really need this for the things the decision is going to choose from – in statistical terms, the “dependent variables”. As long as the package size, city and so on are in the session variable, RTD will be able to correlate them to the choice that’s selected, so you don’t even need the choice models that I mentioned just below. – MR

Now, as we’re looking to create a self-learning model that detects correlations between, say, the day of week and whether a certain delivery company actually delivers on time, we need to create a way of storing for a particular order what day the deliver was booked on, what size of parcel it was and so on. To do this we create a number of “Choice Models” that are used to record what city was delivered to, what day of the week the order happened, anything that we feel might influence the outcome of the delivery.

To set up the mechanism where these models are populated with data, we add a bit of Java code to the informant that receives the customer order details, using a CASE statement to add the relevant choice to the model.

Now that we’ve got some inputs into the decision process, and a way of recording the details of each order, it’s time to think about the decision we’re going to take, which is what delivery company to use for a particular order. Now the decision we’re going to take its going to depend on a number of factors;

• whether the customer is “premium” or not – if they are, we probably want to get them their order a bit faster
• the price each delivery company charges
• the reliability of each delivery firm based on whether it deliverers “first time”

Leaving aside the issue of premium customers for the moment, the price and reliability factors can be boiled down to a couple of performance goals

• cost, which we will want to minimize, and
• chance of delivering on time, which we want to maximize

So the next step then is to put these performance goals into the model – later on, we’ll assign priorities to these, which we can vary for different segments of customers.

Now we’ve got some performance goals, we can score each of the suppliers against them. The cost of each service we can add now, the chance of delivery we’ll add later once we add functionality to predict it into the model.

So now we’ve got some inputs, and some business goals and scores against these for each delivery firm, we can tell RTD that we want to make a decision. To do this, we define a decision that specifies weighting for the performance goals, which can be different for different customer segments. In this case, we’ve only got a single performance goal that’s being populated, so we make the decision 100%-based on the cost of the service, and we don’t distinguish between regular and premium customers.

Now that we’ve defined this decision, we can create an “Advisor”, an output from the decision process that takes a decision and sends it back to the calling application.

As well as using the decision we just defined, we also define a random decision as well, which we’ll use every so often to see whether the models we’re building up are actually improving the accuracy of the decision.

So that we can record what decision was actually made for this order, which we can tie back to the factors that defined the order, we add another bit of Java logic, this time to the Advisor, to record the decision.

So, so far, we’re at the point where we’ve achieved the following:

1. Details of an order come in, we record which city it’s to, the day of the week and so on
2. We’ve got a set of delivery firms, and a set of performance goals, which at the moment is just to minimize the cost of the delivery
3. We’ve scored the delivery firms against this goal, and
4. Set up a decision that chooses a delivery firm based on this goal.

In real-life though, price isn’t the only factor that’ll we’ll base our choice of delivery firm on though. We also want to consider how likely it is they’ll get the delivery to the customer on time, something that depends on the choice of delivery company, where they are delivering to, how big the parcel is and so on. Some firms may deliver well to Manchester and not to London, some firms might be overwhelmed at the start of the week but deliver on time towards the end. Others may handle big parcels worse than small ones, all of which leads to a situation where it’s pretty hard to judge in advance which delivery firm is most likely to deliver on time. Where RTD comes in though is that we can set up another type of model, called a “Choice Event Model”, that records events against a choice, in this case a delivery company, and over time correlates deliveries placed, and deliveries that are then on time, with the order factors we recorded earlier – parcel size, day of week and city.

Now, for each delivery we make, we’ll record whether the delivery happened first time, or whether the customer needed to contact the delivery firm and arrange delivery for a second or third time. Crucially, we’ll record this feedback on the delivery and use it to “learn” which delivery company actually delivers well based on the city, day of week and size of the parcel.

To do this, I go back to the application and define the new Choice Event Model This new type of model takes two events that I assign to suppliers, “Assigned Work Order” and “Delivered On Time”, and records these bits of information for each delivery that takes place.

In case you’ve not already guessed, this is where the “data mining” part of RTD comes in. For this Choice Event Model, I tell RTD to use it for prediction, so that it starts to correlate successful and unsuccessful deliveries with the city, package size and day of week that the order takes place, and I add another Informant, this time to feed back to the Choice Event Model whether the order actually arrived on time.

Again, I add a bit of Java logic to add the feedback to this new model.

Now I can go back to the performance goal scores for each supplier, and tell it to calculate each one’s reliability score based on the DeliveryOnTime Choice Event Model I created earlier.

So now my model has two performance goals; one is static and is based on the price each charges, another evolves over time as we get actual feedback from each delivery on whether the delivery actually reached the customer on time. All that’s left now is to go back to the decision I created earlier and include this new performance goal in the decision. For standard customers, I’ll give equal weight to cost reduction and reliability maximization.

<

For our premium customers though, I’ll create another segment where cost reduction is downplayed and chance of delivering on time in emphasized.

So now we’re ready to go. RTD comes with a load generator that lets you define a script that passes values to the RTD decision process, where you can weight the input variables so that, for example, only 20% of customers are premium and 70% of deliveries happen on time. Running this load generator gives us some basic information to add to the model.

Although the values going into the decision process are random, after a while we’ll start to get some skew which will mean certain choices get made more than others, and we’ll start to get a bit of correlation between input variables and delivery outcomes. To check this out, I start up a web-based console called RTD Decision Center to see how decisions have played out so far.

Taking a look at the distribution of orders, we can see that most have gone to Economy Parcels, who just happen to charge the least for delivering. As the load generator script has assigned a 70% chance of delivering on time to all suppliers, one delivering more reliably than another hasn’t had a chance to impact the decision, but if, for example, Express Delivery turned out to deliver more reliably than all the others, it would end up getting selected more and more times.

Using Decision Center I can take a look at which order attributes were most significant for the outcome we’re trying to predict – delivery on time – so that over time, we can start to understand that the day of the week and the city are the two things that most determine whether a particular company would deliver on time, so that in future, if we have that particular day and need to deliver to that particular city, we’ll know which supplier is most likely to help us meet our business goals.

So there you go, we’ve used RTD and it’s self-learning predictive models to work out, based on the history of previous deliveries against a wide range of different scenarios, which delivery firm to use in a particular situation. I wouldn’t say I’m an expert at this – part of the skill in setting this sort of thing up is to work out how much information, or “rules” to feed in to the model and how much you should let it work things out itself, part of it is working out what we should be trying to predict in the first place – but it’s certainly an interesting technology and a good example of BI becoming “pervasive” and helping business decision making.

Anyway, as a bit of background the last couple of years have seen an unprecedented amount of new products, BI acquisitions and new announcements from Oracle, including the announcement of Siebel Analytics being the go-forward strategy for Oracle’s BI platform, the acquisition of Hyperion, the release of Oracle Database 11g, the inclusion of Oracle BI in Fusion Middleware and the move towards standards and hot-pluggability. Although it’s been two years of near constant change, in my opinion this is only just the start and what we’ll be seeing over the next eighteen to twenty-four months will significantly change and impact the world of Oracle BI developers and customers.

Starting with the most probable and going through to more longer-term, “visionary” things, here’s five key Oracle BI & data warehousing trends to look out for over the next couple of years:

1: Convergence and Interoperability

Over the late-10g timeframe and the whole 11g timeframe, Oracle’s Standard Edition and Enterprise Edition tools will increasingly interoperate. Already, BI Publisher can use Discoverer worksheets as a data source, and Answers reports can be embedded in an Oracle Portal page. Going into the 11g timeframe, Discoverer reports will be able to be scheduled using Delivers, with Delivers alerts being able to be based off of Discoverer worksheets as well as Answers requests.

OWB11gR2 is scheduled to include functionality to enable you to create and load the Oracle BI EE metadata layer, and Oracle BI EE will support Essbase as both a data source and data target. The 11g release the Oracle Database moves OLAP metadata directly into the database data dictionary, whilst Oracle OLAP analytic workspaces will quality for query rewrite and are refreshable using standard materialized view refresh functions. Later on, you can imagine Discoverer worksheets being embedded directly within Oracle BI EE dashboards, and Oracle OLAP analytic workspaces being created, updated, inserted into and managed using standard SQL DDL and DML functions.

2: Developer Adoption of Hyperion FPM Applications and Platform

If like me, you initially thought that the Hyperion acquisition wouldn’t mean much to you, recent announcements by Oracle (listen to this podcast by Joe Thomas, Oracle Snr. Director of BI Applications) indicate that in time, the Hyperion tools and Oracle’s BI tools will share a common infrastructure and technology foundation. Release 10.1.3.3.1 of Oracle BI EE will support Essbase and possibly Hyperion SmartView as OBIEE clients, with Essbase also becoming a supported datasource through it’s XML/A interface.

In time, the OBIEE metadata layer will contain metrics, KPIs and other Essbase and Oracle OLAP calculations, with Oracle’s eventual vision being an integrated business intelligence platform that supports both financial and operational business intelligence, As this vision starts to take hold, it will be increasingly easy for developers to extend their Oracle BI knowledge to such areas as planning, budgeting and financial consolidation, with a common technology platform, metadata layer and reporting UI providing a common, consistent user experience for developers and customers.

3: OLAP Resumes Central Role in Oracle BI Platform

This is one that’s dear to my heart. The past few years have seen a bit of a de-emphasis on OLAP within Oracle business intelligence, with a lack of viable OLAP query and reporting tools (Oracle Discoverer for OLAP frankly not being up to the job) and an emphasis instead on relational reporting – BI Publisher, Discoverer relational and Oracle Answers.

Now though, the tide is likely to change with a revolutionary release of Oracle OLAP and the bringing into the fold of Hyperion Essbase. Oracle OLAP is being positioned as a “data warehouse supercharger” with Oracle aiming for a high percentage of it’s data warehousing customers to install Oracle OLAP and transparently speed up their relational data warehouse queries. For those customers looking for a standalone OLAP server, and for mutli-dimensional query tools and an Excel interface that supports XML/A and MDX, Essbase will be positioned as both a standalone solution, as part of the Hyperion FPM stack and as a way of adding analytics, KPIs and multi-dimensional calculations to the Oracle BI Suite Enterprise Edition stack. For certain types of calculation and analysis, multi-dimensional OLAP technology will always be faster than relational, and now that Oracle have got all of their ducks in a line when it comes to OLAP, expect to see greater and greater emphasis on this option within Oracle’s BI foundation layer.

4: BI Becomes Pervasive and Embedded

Looking further into the future, demand for BI will only increase but not neccessarily in the form of reports, crosstabs, standalone systems and graphs. For the moment, BI is still a minority interest within organizations and whilst 5% of the company might be trained up on Discoverer and have the time and inclination to learn a tool most people have a job to do and cannot afford the context switch that’s needed to go from their normal applications to a BI tool. For the vast majority within an organization, if you can take the value, analytics and smarts within your BI system and embed it directly within their business processes and business applications, you can “bring BI to them” and deliver it within the context of their day to day work.

What this means in practice is integration of Oracle BI with the wider world of Oracle Fusion Middleware, having Oracle BI EE talk to your applications via Web Services, having Oracle BI EE reports, metrics and conditions accessed from BPEL business processes, and embedding Answers and Discoverer reports and graphs directly in applications using technologies such as JSR-168. This is an area of BI that’s only just starting out, but has the potential to broaden the audience for BI from the analysts and planners to everyone within the organization.

5: Decisions Become Automated

Lastly, and going into the future, you can see Oracle BI, and in particular tools like Real-Time Decisions and Oracle Data Mining, being used to automate the actual decision-making process.

At the end of the day, BI is generally used to help you make a more informed decision, and if you can use techniques such as predictive modelling, automated generation of models, positive feedback loops and statistical analysis to make faster, more accurate and more profitable decisions, you can see a future where many more mundane business decisions are taken using business intelligence and data mining tools, leaving us to make more strategic choices and setting performance goals based on broad business strategies.

Anyway, that’s just a few thoughts on some trends that will probably impact on the world of Oracle BI developers and customers, over the next couple of years., If you’ve got any thoughts on this, add a comment to the posting, otherwise in the next day or so I’ll put a posting together on the other part of the keynote, a potted history of some of Oracle’s BI tools.

The first step in this process is to define two choice events that are associated with the cross-sell group I defined yesterday. These two events represent the two events that are associated with presenting a cross-sell offer – what offer we made, and whether the offer was accepted. In a moment we’ll build a second model to help us predict the latter more accurately.

So, now to create the associated Choice Event Model. I call the model “Offer Acceptance Predictor”, associate it with the set of cross-selling choices, give it a window of a week to base it’s predictions on (i.e. disregarding choices made more than a week ago), and tie it into the presented and accepted choice events I defined a moment ago.

I then go back to the session entity definition and add an attribute to hold the name of the offer we’ve presented to the customer, and then return to the Get Cross Sell Offer and amend the advisor logic to record the offer within this new session attribute, using this Java code:

logInfo("Integration Point - Get Cross Sell Offer");
logInfo("  Customer status = " + session().getCustomer().getStatus() );// 'choices' is array returned by the 'Select Offer' decision
if (choices.size() > 0) {
  //Get the first offer from array
  Choice offer = choices.get(0);
  //For the selected offer, record that it has been 'presented'
  offer.recordEvent("presented");
  //Set the session attribute 'OfferExtended' with the offer's ID.
  session().setOfferExtended(offer.getSDOId());
  logInfo("  Offer presented: '" + offer.getSDOLabel() + "'");
}

The advisor that presents the offer to the customer now records the offer selected in the session variable. Next I want to create another informant, this time to record the response from the customer.

I call this new informant “Offer Feedback”, give it the customer ID key, set the external system name and informant order, and create an input variable which will hold the customer’s response.

I then switch to the Logic tab and enter the following Java code to record positive responses.

logInfo("Integration Point - Offer Feedback");
//"yes" or "no" to accept offer.
String	positive = request.getPositive();
positive = positive.toLowerCase();

//Get the offer id from session attribute 'OfferExtended'
String extendedOfferID = session().getOfferExtended();
if (extendedOfferID != null) {
   //Get the offer from choice group 'Cross Selling Offer'
   Choice offer = CrossSellingOffer.getChoice(extendedOfferID);
   if (offer != null){
        String offerId = offer.getSDOId();
        //If response is "yes", then record the offer as accepted.
        if (positive.equals("yes")) {
            offer.recordEvent ("accepted");
            logInfo("  Offer '" + offer.getSDOLabel() + "' accepted");
        }
   }
}

I then save and then deploy the project, to test out this new informant. Running the load generator again, and giving a 30%/70% weighting between offer acceptance and rejection, I can see that the offer feedback is being recorded correctly, and that at the moment, only extended warranties are being offered as they score the lowest in terms of cost.

If I want to, I can adjust the cost scoring so that, for example, customers who have the “Gold” status on their account have the cost metric adjusted up so that it’s less likely to be recommended, for these customers we’d rather recommend something else.

To do this, I define a scoring rule that implements a condition that sets cost to 100 if the customer status is Gold, otherwise it sets it to 30, like this:

I then assign this rule to the Cost scoring setting for the Extended Warranty choice.

Now, if I run the load generator again, I can see the offers being split between extended warranties and gift wrapping.

So far so good. The final step now is to use the offer acceptance prediction model to influence the cross-sell offer choice, so that offers that are more likely to be accepted have a higher chance of being picked by RTD to present to the customer. To show this working, I’m going to create a new metric, “Revenue”, which I’m going to use in conjunction with the prediction model.

I add Revenue as a choice group attribute, alongside URL, description and agent script, and set values for this for all of the cross-sell choices. This will be the baseline revenue figure for each choice.

I then define an additional performance goal, “Expected Revenue”, which I add to the existing “Minimize Cost” performance goal.

Then, I go back to the score setting for the Cross-Sell Offer choice group and add in this performance goal, and set the scoring algorithm to multiply the base revenue for each choice by the chance of each choice actually being accepted, which is a value between 0 and 1 (0% and 100%)

Finally, I go back to the decision I created earlier and factor revenue into the decision, weighting the decision 50/50 between cost and revenue:

Now, when I run the load generator again, the choices are far more spread amongst the five options, as we now factor expected revenue into the choice which itself is adjusted over time as certain offers get accepted or rejected.

So there we have it; we’ve created a feedback loop where customer acceptances and rejections over time are fed back into the predictive model and influence the cross-sell offers being presented to customers. Next week, I’ll take a look back at what we’ve built using Real-Time Decisions, and think again about how the ideas used in this particular real-time marketing project can be applied to our original scenario, deciding which supplier to use to fufill a customer order.

The first thing I have to do is to create a cross-selling offer choice group, and then create some offers to present to the customer, like this:

Next, I need to create some performance goals, by which we’ll later on measure the various offers. The first performance goal is “Cost”, and I’ll set our objective to be to minimize this value.

I then go through each of the cross-selling offers and assign a cost score to them, telling RTD that some offers cost our organization more to offer than others. These costings can be made conditional, so for example it might cost us less to offer an extended warranty to older customers, who claim less, than to others. Later on, I’ll add Revenue in as another performance goal, and we’ll score each option based on it’s ability to contribute revenue.

I’m now at the point where I can create my first “decision”. Decisions use one particular set of performance goal weightings and feed back to the calling application the decision made by RTD. I create a new decision and call it “Cross Selling Offer”, I point it towards the cross-selling choice group, and place a 100% weighting on the cost reduction performance goal. Note how I can segment customers within this dialog – later on, I’ll use this to apply different weightings to different groups, emphazing cost reduction more for silver and bronze customers.

I then create another decision, this time a control group where I check the “select at random” box, to allow us to compare random results with results from the predictive model.

Now that I’ve created the decisions, I need to create an “Advisor” to send the offer recommendation back to the client. I therefore create an Advisor called “Get Cross Sell Offer”, select the predictive model decision and the control (random) decision, and then picked the extended warranty choice as the default offer.

Next, I add some logic to the decision to output the offer that was presented to the customer:

logInfo("Integration Point - Get Cross Sell Offer");
logInfo("  Customer status = " + session().getCustomer().getStatus() );// 'choices' is array returned by the 'Select Offer' decision
if (choices.size() > 0) {
  //Get the first offer from array
  Choice offer = choices.get(0);
  logInfo("  Offer presented: '" + offer.getSDOLabel() + "'");
}

Then I deploy the inline service and test it out.

I simulate a call coming in from a customer who is “silver” status, and who is calling regarding a business order:

Then, when I run the advisor, this lucky customer gets offered an extended warranty, which just happens to be the lowest cost offer, and is therefore picked by the decision which currently is aiming to minimize costs as much as possible.

Now, if I go back to the Decision Center web interface, I can see the revised Inline Service process flow:

Notice the step now where the cross-sell offer is generated, and that I’ve turned off the option to display the “Testing” informant that I created earlier, as it’s not really needed.

So, where we are now is that our Inline Service is generating offers, based a current business priority of minimizing cost. Tomorrow, we’ll add a feedback loop in to feed back customer acceptances, or rejections, of our offers into the model, so that future offers take into account the chance that the customer will take up, or not, the offer.

The problems boiled down to two things: firstly, the only full-scale, keypress-by-keypress example I had was the Oracle By Example CRM cross-selling project available for download on OTN, which although thorough didn’t map too well to the scenario I was working on. I do have a demo around order allocation using RTD, but it’s undocumented and a bit tricky to “reverse-engineer” when I’ve not put a proper, full-scale RTD system together before. So, rather than press on with things not being too clear, I thought I’d restart, but with a slightly simpler scenario that mapped easily onto the OTN Cross-Selling example.

So, in this revised scenario, our customer who has placed the order through the Order Bookings SOA Suite demo, gets a call from our customer service team after the order goes through. The aim of this call is to cross-sell them something, which they may or may not accept. We will use RTD to firstly, model the reasons the customers give for placing the order (a gift, a business purchase, a personal purchase, other), the various cross-selling things we might offer them (express delivery, free gift-wrapping, a voucher off their next purchase, an extended warranty, rechargeable batteries), and whether or not they take up the offer. Each offer will have a revenue figure and cost associated with it, and our performance goals will aim to maximize revenue and/or minimize cost, with different weightings given to these goals depending on which segment they belong to (gold, silver and bronze). So, still a fairly interesting scenario, but one that also maps well to the detailed steps on OTN, albeit with different data and choices so I’ll still need to think about how it gets implemented.

Going back to the start again, this time I define my data source as pointing to a CUSTOMER table, which brings across details of the customer status, credit card type, number of previous returns, previous highest order and the customer ID. I then define an entity which I map to this data source, like this:

I then define another entity, called CALL, that records the name of the agent, the length of the call, and the reason for the order. This entity, together with the customer entity, are then added as attributes to the session entity, whose key is defined as being the customer ID, like this:

I now create two External systems references, once for the Interactive Voice system (IVR) that calls the customer after they’ve placed the order, one for the CRM system that records details of the call.

Next I create three informants:

1. One to record the start of the call
2. One to record the reason for the order,length of call etc at end of customer service section (“Did the order go ok for you, is there anything else we can do” etc) and the name of the agent.
3. one to close the call off, at the end

For the moment, I don’t add any logic to these, although for the second informant, I map the order reason, agent name and length of call to the Call element of the session entity, so they’re available to the rest of the process.

So now, I’m at the point where I was yesterday, but I’m putting an inline service together that’s more in line with RTD’s main purpose – making real-time marketing offers to customers, basing the offer on a model, and feeding their response back into the model at the end to make it more accurate. Later on in the week, I’ll come back to the original manufacturer selection problem and see how this can fit back to that.

So, now to move on. The next thing to do is to create the first of the two Choice Groups i’ll be working with. The first is the set of order reasons that the customer will provide, the second is the list of cross-selling offers I can present to the customer.

To do this, I create an Order Reason choice group, then associate the four order reason choices with it, assigning each of them an ID number that will eventually get stored in the order reasons model:

Then I create the first of the models, in this instance one that I’ll use to store the reasons that customers place orders. I create the model as a Choice Model, associate it with the choice group I just defined, and tell it to get its input from the Call Complete informant, using the Learn Location tab.

Now I need to add some Java code to load values into this Choice Model. I go back to the Service Complete informant and add the following Java code to the logic tab:

logInfo ("Integration Point – Service Complete. ");
logInfo ("  Order Reason: " + session().getCall().getOrderReason());
logInfo ("  Agent: " + session().getCall().getAgent());
logInfo ("  Length: " + session().getCall().getLength());

int code=session().getCall().getOrderReason();
switch (code) {
     case 17:
  		ReasonAnalysis.addToChoice("Gift");
  		logInfo ("  Gift was added to the model");
        break;
     case 18:
		ReasonAnalysis.addToChoice("Business");
		logInfo ("  Business was added to the model");
		break;
     case 19:
		ReasonAnalysis.addToChoice("Personal");
		logInfo ("  Personal was added to the model");
        break;
	default:
		ReasonAnalysis.addToChoice("Other");
  		logInfo ("  Other was added to the model");
		break;
}

When I deploy the project and then run a test on it, I can see that it’s working ok and adding the order reason (Business, corresponding to code 18) to the Reason Analysis model.

So now I’m in a situation where calls are being processed, and we record the order reason, length of call and the handling agent into an order reasons model, which I’ll refer back to later on when working out which cross-selling offer to make (on the basis that, if someone says their order was for business, they’re more likely to take up an express delivery offer, whilst if the order is a gift, they’ll be likely to go for a gift wrapping order, although that might not make as much money for us).

Now, I need to use another RTD tool, the Load Generator, to create a script that will simulate calls coming in, customers giving us their order reasons, and the reason for call, call length and agent name being recorded in the Reason Analysis model. This step involves working with a load generator tool, creating variables and assigning them to the various informants in place in the RTD Inline Service, and then running the load generator to simulate in this case 2000 calls coming into the call centre.

Now I’m going to start up my Web browser and take a look at the results of the generated load. I start up the RTD Decision Center application, log in and take a look at my Inline Service.

Looking at the diagram, I can see the four informants within my Inline Service, and down the left-hand side, the various choices and informants that I created earlier.

If I then look at the correlation between each choice, and the various customer attributes, by far the strongest correlation is between the order reason, and the choice – which is fairly obvious if you think about it.

When I need to do, then, is to take Order Reason out of the predictive model, as it’ll always have a 1:1 correlation between it and the Order Reason choice. I do this via the RTD Studio application, redeploy the Inline Service and clear down the existing model values, then run the load tester again and check the output.

That’s more like it, there’s a weak correlation between the various customer attributes and the order reason, but no huge correlation between the order reason given and the order reason recorded, which would skew the figures. Of course, any correlation that there is, is purely random as the load generator used random figures. Later on, we’ll use proper customer responses, and skew the data a bit, to show how the model works.

Well that’s it for today; we’ve got the various entities set up, together with the main informants, and created a model to record the reasons that customers give for placing an order. Tomorrow, we’ll look at generating cross-sell offers based on various performance goals we set the system, and the day after that, we’ll feed customer responses back into the model to make it more accurately predictive, over time.

Details on the customer and the order will come from the BPEL process that calls the RTD inline service, but details on the various manufacturers will actually be held in a database table that we’ll have to read from whenever the service is invoked. Starting off first with manufacturers then, I create a table called MANUF that holds details on the four manufacturerers and metrics on their manufacturing and delivery history. I’ve installed the Web element of Oracle Real-Time Decisions in to Oracle Application Server 10.1.3.3.1, and so I create a JDBC connection pool, and then a managed data source using the Enterprise Manager Control Web site that maps through to the schema containing this table. I then register this new data source with RTD by following the instructions on page 69 of the Oracle RTD Installation and Administration guide, it basically involves editing four XML files which whilst a bit tricky, does work and makes my new JDBC data source visibile in the RTD Studio application.

Once you’ve got the JDBC data source defined and registed with RTD, the next step is to create a Data Source object within RTD Studio that points through to the JDBC data source, and then use it to import the table metadata into the application. Once you’ve done this, you can select the table columns that you want to make available to the application, and pick one of the columns that will be used as the lookup column.

Now I’ve brought in the database data source, I can now create the Manufacturer entity, which I’ll map to this data source in a moment so that it auto-populates when the service is invoked. To start this process, I select “New Entity” from the RTD Studio service metadata menu, like this:

and then auto-create the entity columns (entities are like tables, they exist at the table-level in RTD applications and have one or more columns associated with them) using the “Import” option. This allows me to pick a data source, suck across the columns associated with one of the tables available through the data source, and then provide a set of default values for the entity, something that RTD requires.

The columns in this new entity are then mapped to the data source columns using the Mapping tab, and finally I press the Key button to define an entity key which is defined as an integer. The final entity looks like this:

with the mapping defined as this:

The next step is to define a session variable that will hold the values of the various manufacturers during the time the service is running. To do this, I double-click on the Session entity in the Inline Service Explorer and then use the press the “Add Attribute” button to add an attribute called Manufacturer, which is then defined as a complex attribute based on the manufacturer entity I just defined earlier.

Finally, I need to go back to the Manufacturer entity settings, click on the Mapping tab and map and use the Data Source Input Values section to map the manufacturer session entity key (which will get it’s value from the BPEL process) to the entity key, so RTD will do an auto-lookup of the manufacturers details from the database when required.

So the situation I’m in now is that I’ve defined a data source that maps to a table containing the details and metrics on manufacturers, and then I’ve used this data source to build an entity which is keyed on the manufacturer ID, with the entity mapping back to the data source so it knows where to get it’s data from when invoked. Then, I’ve defined a session variable of a type “manufacturer”, which is used to hold values of manufacturer entities in memory when the service is run. One thing that I’m not sure of is how we hold details on more than one manufacturer – do we read them into the session variable serially, then feed them into the model, or do we have multiple instances of this session variable, one for each manufacturer under consideration. We’ll have to wait and see.

As well as requiring details on manufacturers, the inline service I’m building also need to hold details on the customer (their name, their status, their credit limit) and details of the order (the order value, the order date and so on). These values will actually come from the BPEL process calling the inline service, and so I won’t need to go through the process of defining additional data sources and using these to create the entities. Instead, I just use the inline service explorer to create the new entities, with customer being created first, and I use the “Add Attribute” and “Add Key” buttons to create the required columns, like this:

I then do the same for Orders, creating an Order entity, adding just a single key (Order ID) and two attributes, Order Value and Order Date.

Next I create two more session variables, one for Customer and one for Order, creating them using the Customer and Order entity types, and defining session keys to map to the keys used by the two entities.

When everything’s set up, the session variables used in the RTD inline process look like this:

So as a process the steps are:

1. Define relational data sources if required.
2. Define the entity, either manually or by reference to an associated data source table.
3. Define the key for each entity.
4. Define a session variable attribute for each entity, with the variable type being based on the entity table definition.
5. Define a session key for each session variable attribute, based on the key for each entity.
6. If the associated entity is auto-mapped to a database table, provide a link between the session variable key and then entity key so an auto-lookup can take place.

OK, so we’re now in a position to test everything out. To do this, I need to create an Informant, an input into the RTD process that we can then use to debug and diagnose the variable initialization process.

I first of all locate the Integration Points, then Informants node in the Inline Service Explorer, and select “New Informant”.

I call the new informant “Testing” and press the “Advanced” button when naming the informant to check the “Show in Decision Center” button (the Web interface for RTD that’s used for monitoring the process of RTD inline services).

On the Testing informant properties page, I press the “Select” button to pick the Manufacturer session key, which is passed as in input into the informant.

Now, that’s got me thinking. In a second, I’m going to add some logic that will display some of the manufacturer attributes for the manufacturer that is referenced by the manufacturer ID input value passed to the informant. To do this, it’ll do a database lookup, using the key and entity binding I created earlier. I wonder, therefore, if I should do all the customer and order details lookups in this way as well, where the inputs to the Inline Service are just the customer ID, order ID and manufacturer ID, and RTD gets all the rest of the information from the database, i.e. not from the calling BPEL process? I’ll carry on for the moment, but I may have to come back and revisit this later on.

Anyway, the next step is to add some logic to this informant, logic that is going to output the diagnostic data we’re looking for. To do this, I click on the Logic tab and type in the following Java code:

logInfo("Manufacturer name = " + session().getManufacturer().getName());
logInfo("Manufacturer accepted orders = " + session().getManufacturer().getNumAcceptedOrders());

like this:

Be careful with the variable names etc, they’re case sensitive – in my case, RTD took the column name NUM_ACCEPTED_ORDERS and turned it into the java method getNumAcceptedOrders, which is referenced through the class session().getManufacturer().getNumAcceptedOrders – it helps with RTD if you’re got a bit of Java knowledge, mine consists of going on a couple of courses a few years ago, but at least I know how to hunt through a bit of Java code, which I had to do in this instance to see how RTD had named this variable/method in the auto-generated Java code.

Now it’s just a case of deploying the Inline service, like this:

Once it’s deployed OK and with no errors, you can use the Test facility in RTD Studio to test it out. I input a manufacturer_id of 1, and get back the correct results.

OK, so where does this leave us?

1. Firstly, we know we can look up details of a manufacturer given a manufacturer ID. HOWEVER, I’m not sure whether this is in fact what we should be doing – we need some metrics on manufacturers to feed into the predictive model, but then again it’s the manufacturer we’re choosing at the end, I’m not sure whether we get the manufacturers attributes from a table like this, or whether they come from the predictive model – we’ll have to wait and see.
2. I’ve defined entities and session variables for customers and orders, but as yet haven’t populated them, as I’m planning to get the BPEL process calling the RTD Inline Service to provide these values as input parameters. I’m not discounting the option, though, of just having the BPEL process pass across the customer ID and order ID, and have RTD get the rest o of the customer and order details from database tables, like we did with manufacturer. This would fit the OTN Oracle-by-example better, but in the scenario I’m trying to built, it’d be more logical to get the BPEL process to provide these values, as it holds them as part of the order it’s processing.

So, some good progress but a few questions that I still need to answer. Tomorrow, I’m going to create some informants for the external systems – the BPEL process, the feedback at the end of the customer order and so on, which should well answer these outstanding questions. Check back tomorrow for some more progress.

As a recap, we have a current BPEL process that takes a customer order, validates it, retrieves some customer information and then gets to a point where it has to decide on a manufacturer. At the moment, the choice is based purely on which manufacturer provides the lowest quote; in the future, we’re going to use RTD to choose a manufacturer based on which one helps us achieve our current business goals, be they to minimize cost, improve customer service, get most orders delivered on time and so on. RTD is going to build up a predictive model that will take information on the customer and their order, take into account contextual information such as the time of year, and come up with the choice of manufacturer that is most likely to help us deliver on our business goals.

RTD projects have five main elements:

1. Entities, the actors in the process
2. Choices, the things that the decision can pick between, in our cases the various manufacturers
3. Performance Goals, the business priorities that can be in effect at any one time – reduce costs, improve customer service, get most orders accepted and delivered within X days
4. The models and rules that are used to make a decision, and
5. The actual decisions that take place

In addition, we need to define Informants, interfaces into the Inline Service that provide data on the customer, whether the decision was accepted, what the customer’s feedback on the order process was and so forth.

Going through this list then, the entities that we will need are:

1. The customer – the person placing the order. Customers will have several data items associated with them including their age, status and so forth. Data on the customer will come from an Oracle database, which will be accessed via the customer ID passed to the inline service from the Order Bookings BPEL process.
2. The order – principally the value of the order, passed to the Inline Service from the BPEL process, and also the number of items, name of the most expensive item in the order and so forth.
3. The manufacturers, their name, number of staff, whether they will take orders electronically and so on.

I mentioned in one of my initial postings that I’ve actually got a very similar RTD project, built by the RTD product management team, that does a similar job – it selects the most suitable satellite TV installer based on a similar scenario and set of inputs.

Taking a look at the project in Oracle RTD Studio, I can see that I might well need some additional entities, to hold manufacturer metrics, real-time data on manufacturers, such us the number of order rejections they’d made in the last hour, day and so on. I’ll have to decide on whether these additional entities are needed when putting my example together.

In terms of choices, these are going to be the various different manufacturers that the decision-making process can decide from. At the moment, the Order Bookings BPEL process uses two manufacturers, “Select Manufacturers” and “Rapid Manufacturers”. To this we’ll add “Bargain Manufacturers” and “Expert Manufacturers”, and we’ll set up the details for each of them to reflect the following characteristics:

• Select Manufacturers will be expensive, provide excellent customer service, and deliver within an average timeframe.
• Rapid Manufacturers will be expensive, typically delivery faster, have average to just under average customer service, but sometimes reject orders because they’re too busy.
• Bargain Manufacturers are typically the cheapest, always take on orders but sometimes delivery them late, and don’t have particularly good customer service.
• Expert manufacturers are expensive, always take on orders, have below-average response times but good customer service.

Within the BPEL process, I’ll introduce a random element such that some manufacturers reject orders and some deliver late. These results will feed back into the RTD model, meaning that over time, a decision might start to change as certain suppliers’ delivery time starts to suffer, their number of rejected jobs goes up and so on. We’ll store these scores and metrics in a database table, and make them available in the RTD project through the supplier entity.

In terms of performance goals, we’ll have a number that we’ll emphasize and de-emphasize at various times. These goals will be:

• Minimize Service Cost
• Maximize chance of delivery on-time
• Minimize rejection rate of work orders

Over time, if we want to maximize customer service at any one time, we’ll emphasize delivering on time and having all work orders accepted, whilst at others, if we’re more concerned with maximizing profits, we’ll emphasize cost reduction instead. If I can work out how to do it, I’ll segment the customers (based on their status, which can be either gold, silver or bronze), emphasizing customer service for the gold customers and cost reduction for the others.

The informants, or events or interfaces into the RTD inline service, will come at three points:

1. When we get all four quotes through an need to pick a manufacturer
2. When we get the work acceptance, or not, from the manufacturer
3. When we get data back from the customer on when the order actually arrived.

The three models we will initially build up will be used to predict the following metrics:

1. Customer Satisfaction
2. Order rejection, and
3. Order completion on time

Finally, we will have one decision that the RTD project will generate, which will be a choice of manufacturers based on our current business priorities, which will be expressed by weighting the various performance goals to emphasize customer service, keeping costs down and so on.

As shown in the screenshot above, taken from the existing RTD demo I’ve got on my machine, it’s also possible to segment customers and apply different performance goal weightings for each segment.

So, that’s the background to the project. Tomorrow, we’ll set up the entities and choices.

Before diving in though, it’s worth taking a few moments to think about some of the key concepts in Oracle Real-Time Decisions.

At the most basic level, what you build in Real-Time Decisions is an “Inline Service”, a process that you can call using in and out parameters that makes a decision for you. The inline process takes your input parameters, runs them past it’s model and comes up with a decision, based on various weightings that you give to your various business priorities.

At the end of the process, you feed back to the Inline Service the actual choice that the customer made, so that Real-Time Decisions can fine tune it’s predictive model in order to come up with more and more appropriate decisions, of offers, for the customer. The Inline Service can either be called via a Java client interface, or we can register it as a Web Service and call it from, for example, a BPEL process.

Within a Real-Time Decisions project, there are five main “elements” that you need to work with:

1. Entities, the main “actors” in a system. Entities have properties and are effectively the variables that you populate at the start of the process, read details from as needed and the load up prior to passing back the decision to the calling application.
2. Performance Goals are the key performance indicators that the the Inline Service tracks and optimizes.
3. Choices, the possible process outcomes, such as as offers, agents, service providers and so on. In our example, the choices will be the various manufacturers that can be used to deliver the order – Select Manufacturer, Rapid Manufacturer, and some others that we’ll come up with.
4. Models and Rules are the predictive models that RTD builds up, and the rules that you define as part of the inline service definition, that are used to work out what score each particular choice attracts, and
5. Decisions take the output of the model, apply weightings based on your performance goals and come up with the most appropriate decision.

Another key concept in RTD is “informants”. Informants are the interfaces into the Inline Service, and provide, for example, feedback on what the customer’s call is actually about, whether they accept an offer, whether they take up the offer some time down the line and so on. All of the above elements, plus the informants and the predictive models, are built up using a tool called Oracle RTD Studio, a Java GUI based on the Eclipse framework that builds up an RTD project in much the same way that you’d build an OWB project, or a Java application.

Tomorrow, we take the Order Bookings process and pull out from it the RTD elements and potential informants that we’ll use in the project.

Real-Time Decisions is effectively a data mining engine that takes on board details, for example, of a customer, adds to it some contextual information – what the customer has rung up about, how long they were on hold waiting for a call centre operator, what part of the year it is and so on – and comes up with a recommendation, or a product offer, that’s most likely to help you meet your business goals.

For example, you may have a call centre application that is used by operators dealing with incoming customer service calls. A customer may call in who’s in your “Gold customers” category, and normally you’d try and cross-sell them a savings account, or a bond or whatever. However when it turns out that they are calling with a complaint, and it’s the time of the year when customer retention is particularly being focused on, Real-Time Decisions might actually recommend a free gift, or a bonus interest rate, or whatever. The key thing is that Real-Time Decisions builds up a predictive model of what offers are most likely to be taken up by particular segments of customers, and it comes up with recommendations that you can influence by emphasizing particular business goals – minimize transaction costs, retain more customers and so on. One of the main differentiators for Real-Time Decisions is that the process of picking a data mining model, and the building of that model, is completely automated meaning that you don’t need statisticians to work out whether to use neural networks, bayesian models or whatever for your predictive model – RTD does all that for you.

I do in fact have a working demo of RTD which I use as part of the Business Intelligence Masterclasses that I run with Oracle University (next venues, Sweden, Hungary, Ireland and The Netherlands), but it’s one that was put together by the RTD product management team and I want to now build one myself, to see how the process works. I have been through the RTD tutorial that you can access on OTN, but again there’s no substitute for building your own demo, working through all the problems and so on, as opposed to working through a step-by-step tutorial.

So, on to the demo scenario. One of the first tricky points that I encountered was to come up with a scenario that matched how RTD works. RTD generally makes marketing recommendation based on a predictive model plus contextual information you feed through in real-time. For my example, I wanted to really avoid having to build an application as working with JDev, ADF and so on is a bit outside my area of competence, so one area I thought of was to add some decision-making capability to a BPEL business process, which would let me build up a workflow but avoid all the GUI development, etc. As the rest of my BI Masterclass is based around the Oracle SOA Suite Order Bookings BPEL process, the scenario I eventually came up with is around picking manufacturers for a customer order.

In the Order Bookings process, customers place orders via a Web interface which eventually make their way, via Enterprise Service Bus, to a BPEL process. The BPEL process then logs the order, gathers some customer information, verifies the credit card number and then gets to a point where it has to decide which manufacturer to use.

It does this by first of all getting quotes from two manufacturers, Select Manufacturer and Rapid Manufacturer, via a Web Service. Once the quotes come in, it chooses the one it wishes to use based on who provides the lowest quote. In my example, I’m going to replace this with an RTD “Inline Service” that takes the quotes, plus some contextual information and information on the customer and order, and selects the most appropriate manufacturer based on my business goals at the time – minimize cost, increase customer satisfaction, give us the greatest chance the manufacturer will accept the order an process it first time (as opposed to reject it, or end up delivering late). This scenario isn’t too far from the RTD demo I currently have (which allocates satellite TV installations based on similar criteria), but it’ll be integrated into the SOA Demo Order Bookings process, I’ll have to figure out the plumbing myself, and I’ll be on my own.

So, in the next posting, I’ll be looking at what sorts of data and processes I’ll need to get the most out of Oracle Real-Time Decisions.

I went throught the basics of a Real-Time Decisions project a few months ago when I worked through the tutorial (there’s a much more comprehensive Oracle By Example walk-through now available on OTN), but for the masterclass, I wanted to show how a basic model was built and then interfaced into the world of BPEL and Service-Orientated Architecture. Now I won’t go into the full details of the example – you’ll have to come to the event for that – but at a high level, we have a BPEL process that assigns contracts to install satellite TV to one of a number of service providers. In the past, contracts were assigned based purely on who could offer the best price; now, we want to incorporate a number of factors, such as whether the supplier did the job once and didn’t need to be called back, whether customers rated the supplier well in subsequent customer surveys, whether they commonly reject jobs, and so on. Moreover, we want Real-Time Decisions to use the past history of service provider events – survey scores, work rejections and so on – to predict, with increasing accuracy, which supplier will be most appropriate for a job, with the underlying predictive model getting more and more accurate as we provide it with feedback from the informants.

So, how is the decision model put together? Firstly, a new Inline Service is created using the RTD Design Center application, a customized version of Eclipse. Once the project is created, data sources are defined together with the internal data model – “entities” and “session variables” – that the Inline Service will use.

Then, “Informants” are created, which are the inputs into the predictive models that we’ll create in a minute. Informants tell the Inline Service, for example, whether a supplier did the job within the required time, what the supplier scored in the subsequent customer survey, whether they rejected the job and so on. The BPEL process I’ll create later on will provide values to these informants through BPEL variables.

Next, we create the list of choices for the Inline Service to make, which in our case are the list of service providers that the decision service can choose from. Then, we create a number of predictive models, one for each metric (“on-time performance”, “customer satisfaction” and so on), and then define performance goals which we then link to these metrics to to allow us to emphasize, for example, arriving on time, minimizing cost, only needing one visit to do the work and so on.

Now, we create one or more decisions. Decisions are things such as “Provide the best performing service provider”, and take the metrics available for each service provider and apply weightings to them, so that for example we might place more emphasis at one point on keeping the customer satisfied with cost minimization a lesser goal; later on, we might define a new decision that changes the weightings and provides a service provider much more based on their ability to get to the customer on time.

Finally, we define some Advisors, the interfaces “out” of the Inline Service, that will be called from the BPEL process to get a decision on, in our case, the best service provider. Each advisor uses at any one point a particular decision, this allows us to emphasize at the start, say, of a year, customer service, whilst at the end of the year, when the figures become more important, we can switch to a decision based more on keeping costs down.

After deploying the service and running some sample data through it to provide values for the models, I can then view the Inline Service using the Decision Center application, like this:

…and then incorporate it into a BPEL process, to be used as the means of picking the most appropriate service provider based on my current business goals, and the predictive powers of the KPI models I’ve created. Within the BPEL process, I pass values from process outcomes and variables back into the Inline Service via the Informers I created earlier, creating a positive feedback loop that’ll help the models learn and make better predictions later on.

Note that the above BPEL process uses straight Java calls to invoke the decision engine, send values to the Informants and so on – in a real deployment, we’d use Web Service calls, Assign process activities and so on, but the Java client was faster to set up for us so we used it for the initial prototype.

Anyway, that’s what I’ve been up to for most evenings over the past few days, and thanks to Michel, Pierre and the RTD team for working with me to get it all up and running. Other than that, as a bit of news I’ve been made one of those Oracle Regional Fusion Middleware Directors (they’ll obviously let anyone in now…), Jon’s Macbook hard disk self-destructed earlier in the week which meant he *had* to go out an get a new 4GB Macbook Pro to replace it, and we’ve set up a mailing list for Rittman Mead Consulting so we can send out the occasional newsletter about what Jon, myself and our team are up to, where we’re presenting, any consulting and education special offers, and a few “exclusive tips” that we’ll save for newsletter subscribers – sign up here if you’re interested (promise, no spam).

Apart from that, some more dates are getting added to the masterclass agenda – We’re doing another date in the Netherlands, so that’s 6th and 7th September, and the 25th and 26th October, plus we’re also doing Hungary on the 11th and 12th October – contact the local Oracle University offices for booking details, once URLs are available we’ll put them on the Masterclasses page. Also, if you’re thinking of coming to one of the one-day events in Hong Kong, Singapore, Austrialia or New Zealand, make sure you book up soon as Oracle will either give the events the go or no-go at the end of July, depending on numbers – so don’t leave signing up too late otherwise it might get cancelled. For me now though, it’s a weekend of kids’ parties – it’s our son’s fifth birthday party on Saturday, there’s one to go to before that, and two on Sunday, so no doubt getting to work on Monday’s going to be a bit of a rest.

Have a good weekend….