Enterprise Decision Management - a Weblog

« February 2007 | Main | April 2007 »

March 30, 2007

Action "0" when building an analytic organization

I saw this article by Peter Graham "Building the Analytic Organization". Peter lays out some steps to create an analytic organization but I think he has failed to list the first one! Action "0" must be to establish why you want to use analytics - what is the business purpose? This might be at an organization level or you might have several more local objectives but you must have them. Otherwise you will just be collecting and analyzing still more data without a clear business purpose. This also applies to each individual analytic model - what is it's business purpose is the first question to ask. This focus on a particular business objective, a unique analytic competency, is at the heart of Tom Davenport's book Competing on Analytics.

The other point I wanted to make about the article is to refer readers to this post (and related discussion) on whether analytics should be centralized or not. Me I think centralization is a consequence of success, not a pre-requisite but I also think the jury is still out.

Lastly, if you want some basic information on predictive analytics, check out the Predictive Analytics FAQ.

Technorati Tags: analytical competitor, analytics, BI, competing on analytics, predictive analytics, predictive model, BI Review

Share:  

Posted by James Taylor at 3:21 PM | Comments (0)

Interesting use for predictive analytics in insurance

I heard about a fascinating use of predictive analytics recently. The company concerned is DriveCam, who focus on improving risky driving behavior by predicting and preventing crashes. They provide an exception-based video event recorder that captures sights and sounds inside and outside a vehicle. G-forces (e.g. hard braking, swerving, collision, etc.) cause the recorder to save the 10 seconds immediately before and after the triggered event. This clip is routed to the operation center for review were a risk analyst scores the clip for risky behavior. If the clip scores high enough then a "coach" reaches out to a fleet manager (or the parent of a teenage driver) and makes recommendations to change the driver’s behavior. The idea is to use video clips of a driver to modify their behavior BEFORE they get into an accident.

Now accurately pinpointing and weighting contributing factors is a daunting task and DriveCam is using predictive analytics to sift through the mass of data to more effectively and accurately identify patterns of behavior. In particular, obviously, to predict which patterns represent higher risk driving. These predictive analytics can then be used to identify trends in the data from each clip to help find the ones that should be reviewed and acted on. Not only does this help DriveCam do its job better, it also puts in place a "decision service" that can be constantly improved. Experience is that the analytics will likely become more effective as more is learned, reducing the rate at which new staff must be added to handle business growth.

You can hear more about DriveCam in their presentation"Cutting-Edge Analytics using Audio and G-Force Data" as part of the analytics track at InterACT. Don't forget there is a blog discount code for InterACT (CRJT90)

P.S. You could imagine adding this kind of technology to improve Pay-As-You-Drive Insurance.

Technorati Tags: analytics, decision service, InterACT, predictive analytics, predictive model

Share:  

Posted by James Taylor at 10:37 AM | Comments (0)

March 28, 2007

Knowledge-driven decision support systems and Decision Services

This week's Ask Dan! in the email I get from DSSResources.com was "What are the features of a knowledge-driven DSS?". In this article Dan Power discusses what I would probably call expert systems. He says:

"In general, a knowledge-driven DSS suggests or recommends actions to targeted users. This type of DSS has specialized problem-solving expertise relevant to a specific narrow task. The "expertise" consists of knowledge about a particular problem domain, understanding of problems within that domain, and "skill" at solving one or some of these problems."

While business rules are often used more to replace human decisions than to support them, they blur into the kind of systems Dan is discussing as many allow for some choice by users and most refer a percentage of transactions to a human operator. It seems worthwhile, then, to consider how a Decision Service compares. Dan had 11 items that characterize these systems, so here goes with some notes on each when it comes to decision services:

1. Asks questions
   While a decision service might have an interactive dialog, often the information is "pushed" into the service rather than built with questions. This is a reflection of the forward-chaining approach to rules-based decisions and contrasts with the backward-chaining approach of expert systems
2. Backtrack capability
   This is not typically a feature of a decision service and deliberately so. By and large the rules that should be followed are defined and there is little need to go back and forward in this way. Indeed, as most decision services are trying to make a decision absent human interaction, this is largely moot anyway.
3. Display confidence or certainty information
   Most decision services will refer a transaction that cannot be processed. When referring it, the service may well describe why in ways that display confidence or certainty information. The ability of a decision service to refer something and explain why it was referred is a key benefit. Additionally, the use of predictive models may help manage uncertainty in decision services. For example, the use of predictive scorecards to handle risk predictions helps manage uncertainty by calculating a score from many additive factors, putting a numeric value on uncertainty.
4. Explain HOW
   A feature common to decision services and one of their key advantages over traditional code - explainability. A decision service knows exactly what rules and what models fired for each transaction and can log this. This allows for review and compliance.
5. Explain WHY
   Something that is sometimes built into decision services but by no means a common feature, largely because they are not interrogative the way an expert system is.
6. Initiate actions
   Absolutely - this is what decision services do, or at least what they cause to happen. Decision Services cause actions to be taken, they don't just add to the body of knowledge.
7. Output selection
   Not usually, most decision services are focused on a particular output.
8. Resume analysis
   The ability to resume a decision is common when external data sources must be consulted. This is often not handled as "resume" so much as "retry with new data", however. Decision Services are designed to work inside transactions and so waiting and resuming is often not an option.
9. Retrieve data about a specific case or instance
   Always a feature of decision services as they are built to interact with corporate information systems. This data might be passed in or retrieved by the service as it needs it but it is going to access real data.
10. Store inputs, results and user actions
    Logging is a common feature of decision services as noted above.
11. Train users
    A decision service does not usually train users unless that is its ultimate purpose. The idea that using it will make the person able to not use it does not really come up.

So there you have it. Some similarities, some differences.

Technorati Tags: business rules, Decision Automation, decision management, decision service, DSS, knowledge management, decision support system

Share:  

Posted by James Taylor at 4:03 PM | Comments (0)

March 27, 2007

More on requirements gathering

Another great post on requirements from Scott over on his blog - Types of requirements gathering. Worth reading as good background for anyone gathering requirements and rules (which are not the same, remember). A couple of rules-centric comments first:

• Rules derived from regulations and policies are probably going to fall in the "known" category
• Always add the original policy manuals and regulations to your document search - there's often a ton of rules there
• When using existing systems it is really important not to blindly extract rules as you will end up with very technical ones, not business rules
• You might find some rules or rule types using the "unknown" requirements techniques but you will likely do better if you focus on types of rules and let the development and evolution of rules happen later (by empowering business users to make their own rule changes) - this will better support change-time and business agility

As for analytics:

• Replacing existing analytics is the only way they are likely to show up as "known" requirements
• Using analytics to add value in a new way is almost certain to be an unknown requirement - people will need to be poked to come up with new analytics. "What if you could predict this, would it help?"
• You can try watching experts and see what reports they use. Asking them why they use that report, what they get out of it, can be a good way to find new analytics too

In general you need also to keep asking "what decisions are you making" or "what decisions is the system making" to find the decision services you will need.

Technorati Tags: analytics, business agility, business rules, knowledge management, predictive analytics, requirements, Tyner Blain

Share:  

Posted by James Taylor at 12:34 PM | Comments (0)

An Airline Story

Last night I was supposed to fly back from San Diego on American Airlines. The experience showed me, again, how customer service could be improved with Enterprise Decision Management (EDM). Let's see...

Old Way

• It's 7:30pm. The 7:30pm flight is still showing "On time" even though boarding has not started.
• "We're waiting for maintenance and don't have a time yet"
• At 7:45pm we are told that maintenance will make a decision at 8:15pm
• At 8:25 or so the flight is canceled and we are told we will be on standby for the 9:40 flight
• In fact we are not on standby until we re-book with the agent so gradually we all do that
• At 9:30pm about 6 of us are told that there is not space on the plane (only 9 people actually got seats on the later flight). The 9:40 flight is the last flight to San Jose - all alternative flights have already left.
• We go and wait at the ticket counter while the staff call around, hotel by hotel, to see who will honor the "distressed rate" that is all American Airlines wants to pay. By 10:30 pm we have a hotel room and a shuttle and are re-booked on flights in the morning.

It seemed to me then, and seems to me now, that this process could be improved using EDM. Now, to be fair, EDM could not prevent the problem with the plane (though perhaps an EDM-driven maintenance system would have done better), nor could it have made the later flight bigger. EDM alone would not make American Airlines act less cheap and offer incentives to people willing to give up seats on the later flight (as they do when they overbook a flight) nor would it have helped the staff remember that the hotel shuttle did not run early enough in the morning (forcing me to go through the hassle of getting them to refund a cab ride). But it could, I think, have improved the experience. Here goes.

EDM Way

• It's 7:30pm. The 7:30pm flight shows "Probable Delay"
  Rules have combined the lack of boarding with the maintenance call out and flagged the flight as probably delayed
• As maintenance continues to work, the actions they take update the status of the flight
  E.g. to "Delayed, possible cancellation"
• At 7:45pm we are told that maintenance will make a decision at 8:15pm
  At this point two things are true - the odds that the flight will be canceled have risen dramatically (any long maintenance delay is a bad sign) and the consequences of the cancellation are known.
• The system identifies the passengers on the 7:30pm flight likely not to get a spot on the later flight.
  It uses models and historical data about the flight to assess the most likely number of passengers who will actually show and figures that 8-10 spots will be available - there is no reason why they should wait until they board the plane. Yes, it is possible that this flight will be different from all others in terms of no-shows etc, but it is very unlikely. It has prioritization rules (based on ticket price, frequent flier status, check-in time and so on) that enable it to identify the passengers who are not going to make it.
• The system also flags some passengers (either delayed or on the later flight) who live locally and suggests that the gate staff offer them an incentive to stay home one more night and fly in the morning.
  This involves airline travel dollars but avoids hotel charges for those passengers, likely a better deal for the airline
• At 8:25 or so the flight is canceled and everyone is put on standby for the 9:40 flight automatically
• Rules check for other flight alternatives and trigger the gate staff to call up those most likely to not make the flight. Alternative flights are offered to these passengers as "You are not likely to make the later flight".
• At 9:30pm a couple of passengers are told that despite everything there is no space on the plane and told what hotel they are staying in and where to meet the shuttle
  The system has communicated with the hotel systems to find spaces based on the most likely number of passengers who will have to stay over and has this information ready for the gate agent.

So why is this better? Well customers are better informed and get more chance to influence the process. The system is proactive not reactive, minimizing the impact on the customers as a group and on individual customers. The gate and other airline staff can focus on the customers as the system is working on the mechanics. I know that I would have preferred it.

Written sitting in San Diego airport at 5:30 in the morning unshaven and in the clothes I wore yesterday...

Technorati Tags: business rules, customer centricity, customer experience, customer service, customer treatment, Decision Automation, EDM, Enterprise Decision Management, predictive analytics, airline

Share:  

Posted by James Taylor at 5:08 AM | Comments (0)

March 26, 2007

Business Rules and SDLC - some questions

Bhaskar Sharma of HCL wrote me a little while ago and asked about business rules and the software development life cycle (SDLC). He said that, as of now, they use a normal SDLC approach in which rules are either hard coded or manually written in an xml file with lot of supporting code. He had come across business rules management systems (BRMS) or business rules engines (BRE) (and there are not the same thing) and said that initially there was a poor reception to proposing their use. In particular he asked for my comments on 7 areas of confusion. He and I agreed I would answer these here on my blog so that you could all share and enjoy (and comment). Here they are, his text in italics with my responses. Thanks to Mark Eastwood from our professional services group for his help. For some basic thoughts on why to use business rules, check out this FAQ posting.

In general, many aspects of a traditional SDLC do apply when using business rules. There is “infrastructure” required that must be developed by IT such as glue code and definition of complex rules or rule templates. Once IT has completed this development, users have a way to make changes to the system without going through the usual SDLC, but building the environment to do this requires a proper software process. You do need this second, shorter and simpler process that goes from business requirement to the business user making and testing the change Users can also be allowed to push these into production but most IT departments still want at least a partial release cycle.

This is a little like using a database in the sense that designing the schema is a fairly complex IT process while using a UI to add rows within the constraints of the schema is a user-centric task. Adding a rule is somewhat like adding a row to a table or modifying a particular column of a particular row.

So Bhaskar's questions

1. How's my application going to interact with the rule engine
   There are as many ways to do this as there are platforms! Most business rules vendors' products (including Fair Isaac's Blaze Advisor), allow you to package up all the rules that go into a business decision and then deploy them as a service, an EJB, a COBOL program, a .NET assembly or whatever makes sense in your environment. Indeed Blaze Advisor let's you do all of these from the same rules. The important thing to remember is that you are defining logical decision services that provide decisions for other services in your application. You don't need to use SOA to do this but you do need to think about the business decisions you are automating.
2. For a application of moderate size e.g. 40 man months, will it be beneficial to go for a BRE
   Yes. If it meets at least one of 5 basic conditions - there are a lot of rules, the rules change often, the rules are complex, the rules require deep domain expertise to understand, or the business has explicitly requested control over the rules. Small projects work (I know of happy customers with 30-50 rules) and large ones work (75,000 rules ).
3. How does it impact maintainability and enhancements in the future
   We have customers who have made 30-40 significant changes to their rules and made those changes to their production systems without using any IT resources. We have customers who have reduced application maintenance teams from 50 to 5. Maintenance reductions of up to 80% are well documented and Gartner has said that adopting rules can result in a 5-40% reduction in maintenance costs. Business rules allows for more rapid, more agile changes with less IT resources. There are some case studies on the blog.
4. What will be the performance impact as we are adding an extra layer with xml behind it.
   It seems to me that you are worried that an XML repository will slow things down. However the rules are compiled into memory and interpreted much like Java source is compiled into byte code and then interpreted by the JVM. Some applications will run faster, other’s maybe not, but rarely slower. Part of this is the efficiency of the algorithms like Rete III for selecting rules when there are many possible rules. Business rules can frequently knock down the number of rules by an order of magnitude or more making it more efficient to execute and to maintain.
5. How costly it is and for how big an application should I go for it
   It doesn’t have to be too costly - relatively small rule services can be built very quickly and cheaply and provide a nice ROI. There are some open source rules products and commercial products that are cheaper, but even the best products can be adopted for $50,000 - $100,000 for small projects.
6. Do I need to write some extra code or buy something else to test the application built on top of BRE.
   Business Rules Management Systems generally contain extensive testing and debugging tools and these are becoming progressively more extensive, handling scenarios and regression test for instance. Some customers write a custom test harness and some use nUnit very effectively for testing.
7. What is the learning curve of an developer and again, taking this into consideration, for how big (in terms of man month) applications should we go for it
   The training classes are short, but that’s not the question. Its like many other things such as the first time someone developed with .NET or Java - it depends, but its not overnight. Maybe 2 or 3 months, given that you realize there are different levels of proficiency. Projects of any moderate size (40 man months for instance), typically find that they recover the learning time in shortened development provided they get some support. Subsequent projects show a real return. Also, not every developer will be focused on rules, some will still work on "code".

That's it, hope that helps. There some more on rules and RUP and on rules and agile as well as a conversation with Scott Ambler about agile.

Technorati Tags: application development, BRE, BRMS, business rules, business rules engine, Decision Automation, decision service, maintenance, offshore development, Rete, business decision

Share:  

Posted by James Taylor at 4:41 PM | Comments (0)

March 23, 2007

A word about analytics

I was wandering around our Ramp;D facility yesterday and saw a great sign

Analytics simplify data to amplify its value

Now I have no idea if this is original or a well-known analytic quote. Regardless, I think it is very relevant:

• Most business users would say they want usable, actionable information not just data
• Analytics amplifies value by replacing large amounts of data with a statement encapsulating what that data implies
• Better data adds no value. Better decisions thanks to better data do.
• Analytics turn data into a prediction that helps make better decisions
• Front-line staff and self-service websites can't analyze data during a transaction
• Analytics use the data to drive a better response

And so on. It was just such a great phrase I had to end the week with it.

Share:  

Posted by James Taylor at 1:20 PM | Comments (0)

March 22, 2007

Harnessing the Power of Enterprise Decision Management To Drive Retail Growth

Share:  

Posted by James Taylor at 8:08 PM | Comments (1)

Business Rules and the Rational Process

Periodically I get asked about bringing business rules into the Rational Unified Process or RUP. RUP and the Enterprise Unified Process are designed to apply UML and best practices in a formal way. They do not formally manage business rules but consider them part of Use Cases or of requirements. To design decision services successfully, you will need to manage business rules more coherently. RUP outlines six best practices that business rules really support:

1. Develop Software iteratively
   By designing decision services to encapsulate your business rules, and managing those rules as atomic items, you can develop amp; test business rules separate from other software components. This ability to iterate continues into "change time" once the software is deployed thanks to the rule maintenance capabilities of most business rules management systems.
2. Continuously verify software quality
   Business rules are easy to verify as they are close to the business. Rules management encourages constant monitoring and this improves software quality. Business users can really give you feedback on rules in a way they could never do with code.
3. Control changes to software
   Traditional software systems can be “brittle” � small changes can break them. Decision services built with usiness rules are expected to change and can be updated individually even in 24x7 environments.
4. Manage Requirements
   While business rules should not be managed like requirements, they should be managed in parallel with them. Rule management provides a means of managing "requirements" as explicit business rules, throughout and beyond application development.
5. Use Component-based architectures
   Decision Services separate business logic into re-usable, manageable components.
6. Visually model software
   If “a picture is worth a 1000 words” then business rules could be worth many lines of code. Business rules and their interrelationships can be visualized and management more easily than code, resulting in more of the application being managed more visually.

Several changes are typically required:

• Add a Business Rule or Decision Modeling activity alongside Business Modeling that emphasizes the collection and organization of business rules. This replaces a singular focus on use cases with a more balanced view of use cases as a means of rule discovery but not a place to manage them [see above not on rules not requirements]. This activity also has highly compressed interactions between rule modeling and analysis/design/implementation. You need to manage these “source rules” and map these to the use cases and design requirements you are documenting. Source rules are generally in the language your business users would use � both in terms of being in English, for instance, and in terms of using business phrases and terminology. Effective management of terms and vocabulary for these rules will make it easier to check them and easier to map them to additional analysis artifacts. In general, source rules should be kept at a high level. I blogged recently about a great post on the use of Use Cases and Statecharts to find business rules by Scott, who posted some thoughtful comments here. I also reviewed a great book on use cases and rules here.
• Formally identify Decision Services as the components that implement business rules and manage these as a type of component. Decision Services will need to have object-specific rules (that is rules written formally to act against the objects in your system) that drive the decision. As you develop your object or data model, you can start to develop rules that execute against that data. These rules must be managed in a repository, versioned and structured to allow for re-use across Decision Services. These business rules will map back to source rules, though not typically in a simple fashion, and will be collected into rulesets.
• You will need to develop a separate rule maintenance process outside your regular process, especially if business users are maintaining some of the rules in your Decision Service. While you will want to go through many of the usual test and QA steps, realistically you will need a different process as the time frame will be shorter and the changes more frequent than you expectations for a typical IT project.

If you are interested in agile development, by the way, I have posted a virtual conversation with Scott Ambler and an article on this topic for InfoQ.

Technorati Tags: Agile, application development, BRMS, business rules, decision service, development, Enterprise Unified Process, Rational Unified Process, RUP, change time

Share:  

Posted by James Taylor at 3:43 PM | Comments (0)

Business rules or decision management or what?

Tom Debevoise has an interesting question over on his blog - Business Rules: An unfortunate term for a larger concept. He is interested in what others think we should call this over-arching concept. He likes Decision Governance, I (obviously) like Decision Management. Decision Automation? Decisioning? Decision Service Design? What do you think? Post comments here or on his blog.

Technorati Tags: business rules, Decision Automation, decision management, decisioning, decision-making, Enterprise Decision Management, Tom Debevoise

Share:  

Posted by James Taylor at 9:17 AM | Comments (0)

Use Cases, UML Statecharts and business rules

Interesting post over on the Tyner Blain blog Use Case vs. UML Statechart - Business Rules. This post does a good job of differentiating between use cases and UML statecharts with a view to finding the business rules. Of course, it goes without saying that I think the business rules should be managed as first-class objects in some kind of rule repository, even at the requirements gathering stage, not embedded in the notes attached to either diagram (the post does not make their position clear on this).

Technorati Tags: BRMS, business rules, requirements, statechart, Tyner Blain, UML, use case

Share:  

Posted by James Taylor at 9:03 AM | Comments (0)

March 21, 2007

Business rules, flexibility and rigor

Saw this post on the EDS blog - Does the rigor of business rules free you up to be innovative? Charlie Bess refers to a piece by Ron Ross called Business Rules: When is a Door Not a Door? Like Charlie I think that control of your rules gives you more flexibility as well as more rigor. Let's face it, most systems are so hard to change that you know they are out of date (and therefore not rigorous). And if you can't prove something is rigorous (because no-one who understands what that means can read the code) then does it even matter if it is?

There's a lot on the blog already about business rules (including an FAQ), business agility and compliance (often the purpose of rigor). Using business rules to make what you are doing explicit, and putting the power to change that in the hands of your business users makes you more (and not less) agile while retaining the rigor you need.

Technorati Tags: BRMS, business rules, compliance

Share:  

Posted by James Taylor at 3:52 PM | Comments (0)

Predictive Modeling

Ozgur Dogan wrote a nice, if short, article on Advanced Predictive Modeling Made Simple (Sort of) for Chief Marketer that came my way today. He makes three good, clear points in the article:

• Segment your customers
  Absolutely, Good segmentation can really improve results (like this for instance). Making your segments more and more fine-grained - heading towards "segments of 1" - is essential when dealing with the "long tail" and very beneficial just in general. When you have data that might repay many segments, something like genetic algorithms might be worthwhile.
• Focus on constant improvement
  This is also true but not just about analytic improvement. You must have the operational infrastructure to try and evaluate multiple approaches in parallel to see what works best and to allow you to put the best approach quickly into production. We call this adaptive control.
• Maximize the data you can use
  Analyzing transactional data to find the best predictors, and integrating external data effectively, are great ways to add value to the data you have. So is customer data integration. Just don't feel you have to wait for these things before you can do predictive modeling. They enhance the quality of models, for sure, they are not required.

I would add one more.

• Find and improve the hidden decisions
  I find that many companies make far more marketing decisions than they think they do. For instance, in a marketing campaign you actually make one decision per customer sent a mailer, for instance, on top of the segmentation, prediction, selection and creative decisions you make. EDM is about focusing on these high-volume, often hidden decisions are automating and improving them. This came up before in some posts on micro and macro decisions and customers who have done this have seen tremendous results - 2000% improvements for instance

If you are interested in predictive analytics, check out my FAQ

Technorati Tags: analytics, Chief Marketer, decisioning, EDM, Enterprise Decision Management, genetic algorithm, long tail, Marketing, predictive analytics, predictive model, segmentation, adaptive control

Share:  

Posted by James Taylor at 3:21 PM | Comments (0)

March 20, 2007

Business rules and "Dependency Injection"

Nik Malik posted here on why he thinks a pattern known as "dependency injection" beats out rules engines. I was going to write a long post disagreeing but between Charles Young, who does a great job of responding, and Rajgo over on this blog, I am not sure I have much to add!

When it comes to rules, I believe that management and not execution is the issue for many organizations (such as Sun for instance) and that's the weakness for me in Nik's argument. While "dependency injection" may or may not beat out a rule engine, most of us who are serious about rules use business rules management systems and managing code is just way harder, and less effective, that managing rules.

Sorry for the lack of posts recently, had a deadline.

Technorati Tags: BRMS, business rules

Share:  

Posted by James Taylor at 9:46 AM | Comments (0)

March 15, 2007

39 Insurers Recognized as "Model Carriers": Congratulations to Unitrin Kemper Auto

Share:  

Posted by James Taylor at 1:48 PM | Comments (0)

What you need to know about Decision Services

A key tenet of Enterprise Decision Management is the automation of the operational decisions that drive your business. You need to identify operational decisions and automate them; you also need to separate them out from the rest of your applications so that they can be managed and reused. The best way to do this is to design what I call Decision Services - services in your Service Oriented Architecture that automate and manage highly targeted decisions that are part of your organization’s day-to-day operations.

The first thing a Decision Service does is isolate the logic behind these business decisions, separating it from business processes and the mechanical operations of procedural application code. Treating decision logic as a manageable enterprise resource in this way means you can reuse it across multiple applications in many different operational environments. A centralized approach to decision automation can also eliminate the time, cost and technical risk of trying to reprogram multiple individual systems simultaneously to keep up with changing business requirements. For instance, the rules for paying an insurance claim can be removed from the definition of the claims processing business process. These rules can be managed independently, important as the legislative change cycle is different from the business cycle that drives process change. They can also be re-used, for instance to help customers tell if they have a valid claim before submitting it or to support third-party agents. The same rules can be in multiple decision services.

Having a decision in a single Decision Service makes it easier for you to improve that decision over time. Not only is your ROI higher � improvements in the decision improve results in all the applications that use the Decision Service, change is quicker and easier to manage. This allows you to apply predictive analytics, for instance, to the decision-making process you are automating so as to make the decision more precise. Indeed, with experience, you can apply more advanced analytics and consider the mathematical relationships between business objectives, actions, customer reactions, constraints and outcomes. This lets you take market and economic uncertainties into account and arrive at optimal decision strategies quickly while still isolating any needed changes to a single service or component.

A Decision Service can be used to provide a “brain” to your composite applications. Composite applications are an effective way to assemble existing, working functionality to serve a new business purpose. You can put together bought, built or legacy components and create new applications more quickly. Decision Services, plugged into this approach, allow you to make these composite applications “smarter” and less reliant on people for decision-making. Sometimes this will make it easier to connect existing services, sometimes it will let you take more advantage of the services you have. There is also a cultural component to the managing Decision Services in this way. By recognizing and separating out operational decisions, you can focus your business thinking and investment on these decisions more easily. You can apply your strategic vision and proper management approaches to drive toward optimal decisions.

There is an interesting article on Decision Services by Larry Goldberg on the BPM Institute site - A SOA-based Business Rules Approach: Decision Services and I have a couple of related posts and articles:

• Decision Service definition
• Modeling Decisions
• Pragmatic Decision Services
• SOA and business rules

Others talking about decision services include Fair Isaac, Oracle (whose BPEL process manager allows Decision Services to be integrated as noted here) and ILOG.

Here are some examples from various industries to try and make it clearer:

• An auto policy underwriting service that combines pricing rules and risk models to underwrite policies
• A cross-sell offer service that combines segmentation rules and response models to generate the best cross sell offer across channels
• A fraud detection service that uses rules and a neural net to identify fraudulent credit card transactions
• A shipment routing service that routes shipments to customers based on demand, contracts and status
• A claims payment service that uses rules to check a claim for authorization to pay while also applying analytics to detect potential fraud
• An eligibility service that allows citizens to check their eligibility for benefits and applies state and federal rules appropriately
• A return authorization service that tells front-line retail staff whether a particular customer can make a particular return using return rules, purchase history and future revenue potential

Technorati Tags: BRMS, business rules, Decision Automation, Decision Science, EDM, Enterprise Decision Management, predictive analytics, reuse, SOA

Share: