Enterprise Decision Management - a Weblog

« March 2006 | Main | May 2006 »

April 28, 2006

This is why predictive analytics matters...

I saw this today - California Auto Bill Passes Assembly Insurance Committee - and it prompted me to ask some of my insurance analytic friends. Here's what they came up with:

• There is a clear opportunity for Predictive Analytics to help identify which factors are predictive of fair (or unfair) rate changes.
• Reality is that every year 90% of the drivers do subsidize the 10% that have claims.
• Because there are lots of votes in cities there is pressure from politicians to lower the rates there. However auto crime(vandalism, theft, fraud) , is much higher in city areas driving costs of claims up.
• At the same time, many inner city folk are among those least able to pay for the real exposure.
• Better use of Predictive Analytics could identify which farmers are high risk and which inner city folks are low risk and so properly balance the risk and prices.

This is what multivariate analysis is all about. Just as with credit, some people with good credit scores are still high risk due to other factors and others with low credit scores are better risks because of their good factors.

The bill is right on about one thing - analysis, not politics, should be the driver.

Thanks to Wendell Larson for his expert advice.

Share:  

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

Users look to offer BI access to customers, partners - WHY?

I saw this article in Computerworld - Users look to offer BI access to customers, partners - and the title made me ask "Why?". Now I don't want to seem like I am criticizing the products or companies described - I'm not - but I do think that many organizations assume that offering BI to more people, employees or customers or partners, is inherently a good and useful thing and I think that assertion bears some consideration.

So, do your customers want business intelligence?

• Well, perhaps. A customer getting reports on how their staff are using a travel service is good, customers being able to configure the booking engine and approval process to match their needs is better. If the only way they can respond to what they find out is to implement an internal manual process or make a request to your IT department (which is, of course, backlogged) then that's not very helpful.
• Customers also probably want to customize their interaction with you and have you learn their preferences.
• They will probably appreciate you predicting their needs and taking action to address them in advance.
• They increasingly want to "self-serve" and will appreciate systems that help them do so effectively.
• They want, in other words, to have a say in how you make decisions about your interactions with them.

So, do your suppliers want business intelligence?

• Giving your supplier visibility into sales of their product is certainly useful but why not use analytics to predict outages and rules to auto-alert them?
• Why not allow them some control over the pricing rules your website uses?
• Why not automate the re-order process based on your rules and theirs?
• They want to be part of the decisions you make about stocking, re-ordering, supplying and promoting not just know what your decisions were.

So, do your business managers want business intelligence?

• Having managers see how well they are doing is great, , but why not give them some control over pricing rules too so they can apply local knowledge (like graduation week for the local university)? You'd better make sure the demand-based pricing engine is consistent across the folks at the desk, the folks in the call center and the website too.
• Using visualization and geographic data to show managers how things are working and how well matched sales territories are to business is great. But why not use rules and analytics to tell managers where there are problems or to identify the sales people who are performing outside the norm given their territory?
• Why not give your business managers the power to apply their know-how to the decisions you take as a corporation?

BI can help your customers, suppliers and business users understand your business better and perhaps identify ways that it can be improved. Unless the decisions you make have been automated in a way that brings them into the process of changing those decisions, their ability to drive your business will be limited. EDM is about applying some of these same principles to automation of decisions so that when you get new intelligence about your business you can actually do something about it.

A final word from the article:

Dan Vesset, an analyst at Framingham, Mass.-based market research company IDC, said operational BI -- embedding BI in the business processes used by front-line workers -- is becoming more common as companies seek to give users better tools to make decisions. However, he and users noted that companies must pay closer attention to the user interface for these applications. A common rule of thumb is that training for business users can't exceed two hours, he said

So think hard if you really want your business users to be able to use a report or if you would rather invest that two hours in helping them understand how to drive the business.

Share:  

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

No wonder insurance is so expensive....

ake I saw this today - Ark. Reminds Insurers of Anti-Money Laundering Responsibilities. The article had a key piece about what insurance companies should do:

At a minimum, insurance companies subject to the rule requiring an anti-money laundering program must establish a program that comprises four basic elements:

• A compliance officer who is responsible for ensuring that the program is implemented effectively,
• Written policies, procedures, and internal controls reasonably designed to control the risks of money laundering, terrorist financing, and other financial crime associated with its business,
• Ongoing training of appropriate persons concerning their responsibilities under the program, and
• Independent testing to monitor and maintain an adequate program.

All I could think of was "AAAAGGGGH". Written policies? Ongoing training? Independent testing? How 19th Century!

Here's what I would propose instead:

• A compliance officer who is responsible for managing a set of business rules that demonstrate compliance and for working with law enforcement to update these rules regularly based on current Anti Money Laundering best practice,
• Defined business rules reasonably designed to control the risks of money laundering, terrorist financing, and other financial crime associated with its business that can be reviewed by the business managers and law enforcement at need,
• 100% processing of transactions against these rules to ensure that all potential money laundering activities are identified and raised for investigation,
• Independent verification of the rules and of the process for applying the rules to ensure systematic monitoring of transactions for violations.

Is it just me or is this whole focus on manual compliance just pointless? Why would I try and defeat a problem dominated by terrorists and organized crime with "written policies"? I have written again and again on this topic on the blog under compliance. Ho hum...

Share:  

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

April 27, 2006

What the people REALLY want

A good friend of mine, Ken Molay over at Webinar Success, spotted this article Times have changed, technology needs to follow about the need for new technological solutions as work shifts increasingly to knowledge work.

"86% feel they are being asked to take on higher levels of responsibility when it comes to strategic decisions, calculating risks, providing analysis and developing and running complex projects at all levels of an organization. Nearly all of those polled, 98%, said given the higher levels of responsibility at work they need the right technological tools to increase productivity, reduce costs and increase revenue."

In other words they want their organizations to adopt an EDM-approach. They want to know that the systems that support the business allow for effective analysis of data and use of this analysis at every point of the organization. They want to be able to apply their knowledge so that every user can make better strategic and tactical decisions that reduce operational costs, increase productivity (automation of tasks), and increase revenue.

They are crying out for a new technological infrastructure so that they can perform effectively for the overall good of the organization. That doesn't mean more training manuals, it means models that can be seen and interpreted in a business context, rules-based automation, and strategic decision optimization that is fundamental to every business function. This means having underwriters manage the book of business and the agency network, not approve policies. It means benefits professionals changing the eligibility rules for the employee portal, not reviewing email requests. It means sales management changing the product pricing and commission rules not reviewing every PO. And so on.

"40% want the ability to share documents within a common workspace, allowing colleagues to check documents in and out and work from one central version while enabling everyone to communicate about the project in real time.
32% would like the ability to automatically create and update business processes, forms, reports and documents using the latest back-end IT system, or network, and make the information available through familiar desktop tools."

Forget documents- that's so five years ago. What they REALLY want is a way to collaboratively update the way the business works. That takes a focus on decisioning and a central rules repository with the ability to check functional areas in and out, update rules in real time, synchronize all updates among multiple workers, etc. Then they can change the business not just write about it.

Making a familiar interface to this updating facility meant offering those update facilities through browser pages using the workers' own terminology and a familiar look and feel. What's more it means making this kind of policy change (rule maintenance) something they do as part of their day to day job.

"20% want the ability to control how incoming communications are routed to users based on the system's knowledge of personal preferences, physical location, organizational relationship and topic of communication."

In other words, segmentation leading to rules-based automated operations. , This kind of segmentation is requires rules, analytics, location intelligence and text analysis but it also requires a focus on decisioning and EDM.

These workers will not get the help they need unless their companies can move operational decisioning making into an EDM environment where their knowledge workers can truly use their knowledge to manage and improve the business.

Share:  

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

EDM and your Digital Business Architecture

I was reading some work by Randy Heffner and his colleagues at Forrester recently on Digital Business Architecture - here and here. , He defines a Digital Business Architecture as:

An IT Architecture centered on business metadata on which IT solutions act in a unified and consistent way to deliver rapid business change

Wow - this sure sounds like something that would leverage EDM to the hilt. If I think about customers implementing an "enterprise policy hub" or "enterprise decisioning backbone" they are trying to get control of business metadata (rules) so they can build systems that use this in a unified and consistent way to deliver on agility.

Randy correctly identifies business rules as a form of business metadata for policy definition and goes on to give some great examples. Interestingly one of them strikes me as a perfect example of where rules could have played a role - the process for calculating and approving sales commission. If the rules for calculating this were managed in a business rules management system where the business owners (sales management) could maintain the rules themselves and where, perhaps, the rules could be combined with the pricing engine used by the sales folks, then the calculation could be automated and the whole process dramatically simplified. Indeed a couple of mobile telcos do exactly this with Blaze Advisor, using it to calculate the (notoriously complex) sales commissions on mobile phones and plans .

Later in the paper Randy is talking about how to get to the digital business architecture and he has a step called "how can we optimize each step in the process". This is where EDM comes into play. With its focus on operational business decisions, EDM is uniquely focused on how data, analytics, policy and regulations can be applied/enforced to make the most effective and most efficient decisions at each step - most precise, most consistent, most agile. For instance, instead of using the RFID data to alert someone to a shipment risk, why not take remedial action while that person is asleep? Randy is rightly dismissive of requirements definition and documentation as a vehicle for this kind of thing. Regular readers of my blog will know my position on this but there is a lot more on this here.

EDM is part of how any decision-rich business can deliver on the digital business architecture. If you have decisions, and you want this kind of technology/business integration, you need EDM.

BTW I also blogged about Randy's phrase "Concurrent Business Engineering" and how rules could deliver on this over on ebizQ.

Share:  

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

April 26, 2006

Reduce Fraud? Use EDM...

Interesting article in Insurance Journal ABI Calls for "Radical Action" to Reduce U.K. Fraud talking about insurance fraud costing each family in the UK $1,000 annually. The article talks about some steps that could be taken to improve this situation.

What the article does not do is talk about how software, especially decisioning software suitable for an Enterprise Decision Management approach, can address this. Other industries, like credit for instance, have had great success in reducing fraud using business rules (to target spot fraud or new fraud trends) and analytic models that predict fraud (like neural nets to track out of pattern behavior). One example here is Fair Isaac's product Falcon Fraud Manager. Similarly the same combination works really well in claims fraud here in the US (when there is a political will to use it) - Vericomp Fraud Manager is our product there. This stuff works - it just needs to be applied to the industry.

So what would I suggest? Well I might suggest that the ABI:

• Get insurers to pool data to build effective fraud detection models using neural network or similar technology
• Work with software companies to develop the kinds of software products that can leverage these pooled models and business rules to help detect and deal with fraud
• Then do the other things they listed like push the government to spend more on enforcement etc.

Share:  

Posted by James Taylor at 2:54 PM | Comments (0)

Sense and Respond with business rules

Christian Plaichner wrote a nice article recently in DM Review about Agile Business Process Management with Sense and Respond. There's lots of good stuff in the article but I do think one "clarification" is called for.

In many cases it is not process change that I see happening in response to events. Many core processes are well defined and very stable, with lots of alternate branches defined for most if not all of the , things that might happen. What must happen, however, is that a decision must be made as to how to respond to the event - will one of the existing processes or sub-processes work or must this be escalated? If it must be escalated then to whom? Christian defines agility as the ability to respond to unforeseen developments but I might add that it is also the ability to respond to foreseen but unpredictable developments. For instance, the DMV in California can foresee that there will be changes to regulations, and can design systems and processes on this basis, even though it does not know exactly what change will be requested.

Christian goes on to discuss how you need to adapt to customer demands and other information about how customers preferences are changing. I regard this kind of customer-centricity as decision-focused rather than process focused. For instance, a customer buying a product from me is unlikely to give me any clues that will cause me to change the basic process of ordering, fulfillment and billing. They might well, however, give me clues that lead my risk-based pricing decision to result in a different price or billing terms or that might cause me to make a different cross-sell decision. If the decision points within a process have been automated using a flexible, agile technology like business rules then often the process can be changed for a specific instance simply by having the decision rules pick up the additional context and route the transaction differently based on that.

As Christian develops some of the specifics of an SARI you can also see how injecting predictive analytics into a decision can help - if I can predict the likelihood of delay, say, based on data I have then I can right rules that decide when to re-route something. I don't need to wait for actual delays to occur.

I liked his diagram of an SARI but have a slight variation on it:

BTW Christian's descriptions have a lot in common with some of the things I have written about around Complex Event Processing or Business Activity Monitoring.

Share:  

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

April 25, 2006

Oracle's view on business rules and SOA

Interesting article in Enterprise Architect this month - Rules Evolution in Service-Oriented Architecture - by Bruce Lowenthal.

It's a great article and I don't have much to add to Bruce's comments, so instead I will refer to you to other things I have said about SOA and BPM and some Case Studies that show the kinds of benefits Bruce discusses.

I would just like to add one thing - don't underestimate the power of adding analytics to these kinds of "decision services". Business rules are great for adding agility and ensuring transparency and an SOA approach is great for consistency (rules help here too if your whole architecture is not SOA) but analytics can add precision, making your decisions more accurate, more profitable, less risky etc.

Thanks Bruce.

Share:  

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

April 24, 2006

If only they had used rules...

Ian Graham (of Trireme) pointed out a great example of a government project that should have used business rules - Jobcentre Plus misses deadline. , This story, courtesy of the British Government, tells of a simple increase in an allowance that failed to make it into a system despite a year's notice. As the article says

Software experts say such a minor change would only take so long if the earlier rules had been hard-coded into the software.

I have to contrast this experience with my friends at Egg (also in the UK) who change their rules themselves without IT involvement and who have made 40 changes in 3 years without even having to re-start the rule server and who take 2 days to make a change like this. Or, to use a government example, my friends at the Department of Motor Vehicles in California whose licensing system brings in $4B annually in revenue and who can make a 20 rule change in less than a month. This is not rocket-science, plenty of companies and government agencies are using business rules management systems to build for change.

I'll close with the comment Computing made - We need a change in attitude - "Change needs to be built into IT from the start".

Share:  

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

April 21, 2006

Live from Brainstorm (almost): Business Process Management, SOA, and Composite Applications

Ken Vollmer of Forrester Research gave a nice presentation on Business Process Management, SOA, and Composite Applications. , I particularly liked both the phrase "Digital Business Architecture" to describe these general trends and his comment that we are finally able to treat processes as "business metadata". Clearly I think EDM is a core component of the first phrase and that a business rules management system let's you treat business logic, likewise, as business metadata.

Some specifics takeaways:

• Ken outlined steps of Define, Implement, Execute, Monitor, Optimize and back to Define as the loop you need to create. Business rules play a key role in allowing you to apply your optimizations to your deployed processes.
• He talked a fair bit about complex event processing (CEP), something for which I think rules have great potential.
• He discussed how self-healing processes can be developed that use business rules, analytics and CEP to impact running processes without the need to wait for someone to review a dashboard.
• He noted that there were two broad (human- and integration-centric) and four detailed categories of business process management suites and that companies might find good reason for using multiple. It seemed to me that the idea of adopting "one engine to rule them all" (apologies to Tolkien and a GIGA analyst) would be key - if you used a common rule engine for your core business logic, it would mitigate many of the risks inherent in using two BPMS.
• The ability to configure services was noted as key to reducing costs. Clearly services built with business rules management systems are much easier to configure than those written with code.
• Ken gave a nice case study of a mortgage origination system as composite app. Me, of course, focused on the fact that it still had a person making the decision (where rules and analytics could have automated a huge percentage) and still went and got external data (which must be paid for) before running any kind of decision logic to see if it would actually matter - why pay for a report on the house if you know you won't underwrite the applicant?

Lots of good stuff in Ken's presentation, just a sampling here of my key takeaways.

Share:  

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

Live from Brainstorm (almost): The role of business rules in Enterprise Architecture

Larry Goldberg, of KPI, gave a presentation on the role of business rules in Enterprise Architecture, leaning on both the Rule Maturity Model KPI has developed and the Zachman Framework.

Larry spent quite a lot of time on the various frameworks and how/why to use business rules in them - you can contact him or read the materials for more - but a couple of key points I wanted to make here:

• Business rules are orthogonal to data, network, function, process etc.
  They must be linked and thought of together but managed as their own "dimension"
• Source rules, the kind of near-natural-language statements generated by business executives, do not map 1:1 to technical rules suitable for being implemented in a business rules management system.
• There is no good way to classify business rules into static/dynamic or centralized/decentralized that does not cause problems with specific types of rules.
• Patterns on developing rules services and on managing them are needed but still nebulous.

Interesting stuff. Clearly we have work still to do in terms of how rules fits into an Enterprise Architecture but it is good to see that Larry (and some of the folks in the blogroll below) are thinking about it.

Share:  

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

Live from Brainstorm (almost): The Rules of Automated Underwriting

Mike Koscielny of Auto Club Group gave a great presentation on the value of business rules. As I have described his case before - here - I won't go into too much detail but there were a couple of points I noted in the session:

• Mike's underwriting team has only grown from 8 to 14 in a period when the business underwritten has grown nearly 6x! If the underwriting team had scaled with the business he would now be employing 45 underwriters!
• It only took them 3 months to add the capability to underwriter a new state and only 60 days to start offering a specific member benefit (forgiveness of a first accident for members) that they had been considering for years but never been able to justify implementing given the $400,000 estimate for changing the old system!
• Mike discussed how important regression testing was and how his business and IT folks now collaborate on the testing - a big change from the old system where the business folks thought this was IT's problem.
• Mike pointed out that not only are fewer policies and renewals being manually reviewed than before thanks to the system but that 100% of renewals are being checked (by the automated system) where only a 10% sample was being manually reviewed before. The automation has made more decisions possible, not just reduced the cost and increased the speed of existing decisions.
• Early on Mike got many calls from agents asking about "errors" in the automated rules. The rules were not wrong, the agents had just misunderstood them. This consistency of decision is one of the key benefits. In fact Mike said that two recent compliance inspections had resulted in no criticisms at all from the regulators - the rules based system had performed flawlessly.

There was more good stuff but most of that is in the case studies. I will leave the last word for Mike:

We can profitably win the good business we want to win and lose the bad business we want to lose

Share:  

Posted by James Taylor at 2:55 PM | Comments (0)

April 19, 2006

Live from Brainstorm: Business Rules and Business Process - Perfect together or perfect apart?

I sat on a panel today about business rules and business process and whether they should be separate or combined.

I already have a couple of posts on this topic - here and here - so regular readers (both of them) will know where I stand on this. The panel was somewhat predictable in terms of where vendors stood but there were a couple of interesting items:

There was some good discussion of whether you should always start with rules, always start with processes or always start with both. The consensus seemed to be that you should usually start with both (at least thinking about both the rules and the processes in which they are executed) but that this was not a hard and fast rule (think about a legacy modernization problem where the process implementation is not being changed, just a decision) and that it did not imply that both pieces would repay automation equally.

Everyone agreed it was important to demonstrate success early, regardless or which technology choices you made, and that it was important to think about the enterprise vision even while remaining focused on the first project.

Personally I think we will see both more and tighter partnerships between BPM and BRM vendors and more blurring of the line between them with business rules vendors increasingly supporting some process flow and state management and BPM vendors embedding better rules products.

Lastly I wanted to address a question Barb highlighted before the event but that we did not have time to consider. Her class had raised the following question:

Is there a very gray line between process management and business rules?
Explanation: you can create a model that prescribes that you or an automated system carry out task 1 then carry out task 2 and based on some criteria moves to task 3 or 4.
For ex: task 1 is to determine if a person is a desirable renter based on their financial history. , Task 2 is to determine if the person has brought cars back damaged or late or to the wrong destination. , Task 3 is to determine if the person is a risky driver based on driving record. , These can be modeled and managed as THREE tasks within a bigger process (each task with its own rules) or as one TASK within a process (with a super set of all of the rules), or other combinations. , Is this a gray line or can you make it clearer for us?

I think this example is easy to resolve - there should be one decision task as there is only one business decision - should I offer a car and at what price? This decision might be made available as a service to third parties who resell my car rentals or on my website to let customers get the right price for themselves. It has "business atomicity", a term I just made up. In addition I might add or remove decision steps (perhaps a state makes it illegal to use financial history or I decide to add profitability of the selected car to the decision) without changing the process in any way. If you focus on meaningful business decisions then this is usually pretty clear.

P.S. Fair Isaac has partnerships with most of the leading BPM vendors including, but not limited to, webMethods (an OEM), Oracle, FileNet, Savvion, Fujitsu, Metastorm, DST and Lombardi.

P.P.S I promised to post on available white papers and how to get them. There are several, listed below, that you can get by emailing edm@fairisaac.com

• "Business Case for Blaze Advisor" and an IDC ROI Study for overall business value
• "How Blaze Advisor Works", "Blaze Advisor for .NET" and "Blaze Advisor for Java" white papers with more "how to" information
• Industry specific white papers for Insurance, Telco, Healthcare (Payer and Provider), Mortgage
• An SOA and rules and a BPM and rules one showing how rules fits in these approaches

Share:  

Posted by James Taylor at 6:33 PM | Comments (0) | TrackBack

Live from Brainstorm: The Vision for Business Rules

Barb von Halle gave this excellent overview of business rules. She again showed the KPI Rule Maturity Model. She reviewed some very relevant results from a survey of companies that KPI did around the leading reasons for adopting rules to which I have appended my own thoughts:

• Agility - how fast can I respond to change?
• Knowledge retention - what happens when my experts retire?
• Compliance - can I demonstrate compliance in high volume processes?
• Consistency - can I make the same decision, the same way over and over?
• Stronger strategy/business/IT alignment - can decisions ripple down effectively?

She talked also about four specific cases, for some of which I have great examples:

• Business rules as an additional requirement tool
  No good case study here as I typically don't work with customers doing this. The use case book I reviewed recently - Use Cases - Requirements in Context - is a great addition to your library for this case though. Barb made the great point that you must remember that rules and not the same as requirements as rules have a much faster change cycle.
• Business rules approach leading to a business rules management system
  Well most of my customer case studies are like this but I think Sun's use of Blaze Advisor is a classic.
• Business rules approach used for legacy modernization
  Another common use of business rules and I like to think the award-winning California DMV system is a great example of a $4B system being modernized with rules.
• Business rules approach as a vehicle for business transformation
  The use of business rules, often with business process, to transform a business approach is potentially very powerful and Auto Club Group's underwriting project is a good example.

There was also some great discussion on business rules enabling collaboration between IT and the business (rather than necessarily putting the business "in charge") and on the potential value of a business rules Center of Excellence. She also laid out a vision for the kinds of technology needed to support the full rule maturity model. Excellent as always.

Share:  

Posted by James Taylor at 5:49 PM | Comments (0)

Live from Brainstorm: Making the transition to services engineering

In Brett Champlin's session on the Making the transition to services engineering this morning. A couple of interesting points came up in his discussions of how the processes of delivering services are different from those of delivering products.

• 90% of process time is work waiting to be performed
  • As Brett put it "Queues are evil". This is one of the key ways in which decision management can help in service delivery - automating decisions so that far fewer transactions have to be queued up for manual review. In an underwriting case, written up here, this was from 100% to 1%.
• Service processes are a series of states involving the decision-making process and the experience of the customer.
• Customer acting in the role of co-producer
  • Service processes are more decision-centric and more customer-centric and this makes the power of business rules to act as a platform for decisions and to provide customization key.
• Definition of , "good service" may be different for each customer
  • Hence rules-based personalization.
• Heterogeneity a problem - too much variation from worker to worker
  • Consistency is one of the key values of decision management. If I automate the decision making rules, formalize the assessment of risk and uncertainty using predictive analytics and ensure a single point of decisioning then I get consistency of decision across my people.
• Dimensions of performance hard to measure
  • This is one of the reasons for considering Decision Yield as a way to measure decision effectiveness. The dimensions of performance are different when you are in decision-centric environments. You must consider precision, consistency, agility, speed and cost.

Share:  

Posted by James Taylor at 2:29 PM | Comments (0)

Live from Brainstorm: BPM/SOA/BRM/EA/OPM

Well I am at the Brainstorm BPM/SOA/EA/BRM/OPM conference in Chicago today and tomorrow and just attended the opening panel discussion where the various track chairs discussed how all these pieces fit together. There was a fairly nice picture of the overlap between the various elements but I can't find it online and will have to add it later. Each speaker made some good points:

• Brett Champlin made the point that Business Process Management as a discipline- looking at processes explicitly and trying to manage them - should be differentiated from a software stack. In the context of a discipline the management of business rules (also both a discipline and a software stack) was assumed to be part of business process management. While this does not imply that business rules technology is a subset of business process technology, nevertheless I have to take issue with it. It seems to me that decisions can be managed and improved without necessarily having to consider how the processes that use them might be better managed. Some companies only make decisions and some decisions are useful in their own right (e.g. in a self-service inquiry situation). I do agree that most decisions come up in the context of a process, but not all.
• Bill Ulrich talked a little about Enterprise Architecture and drew some nice distinctions between merely using web services wrappers and actually developing an SOA.
• Tom Dwyer of Yankee Group, who wrote a nice report on this "Adoption of SOA Should Stimulate Strategic Demand for BPM, BAM and BRM", showed a fairly standard SOA chart with a clearly defined business logic layer. It seems to me that business logic is almost a synonym for decision logic in this context and so it would make sense to always build the services in this layer using a decision-centric technology like a business rules management system.
• Barb von Halle of KPI spoke about business rules and presented KPI's Rule Maturity Model. Interestingly no-one in the audience would put their hand up and say that their rules were implemented consistently across processes and systems. No-one! Barb herself said that no-one is at the top level of the model and that they are only aware of 1 company at level 4 even.
  Interestingly a book I reviewed recently -Use Cases - Requirements in Context - would be a great tool for someone trying to move from level 0 (no management) to level 1 (awareness). Moving on to level 2 is where a business rules management system comes in and, frankly, where much of the payoff comes.
• Alan Ramias talked about Performance Management and made a great point that you want performance (that is business performance) not technology or training (or methodology or...). The point of EDM, like any approach, is to improve business performance. If it is not doing so then don't do it.

Lastly there was a spirited discussion of how to get started with many different opinions - almost as many as panelists - but the best comment was one that you must start with the business objectives at hand as this is what drives budgets and energy. If the business objective is about improving a process, then focus on that. If the objective is to improve self-service for customers, then think about how to do that. Make sure the business objectives drive the technologies and approaches prioritized and not the other way around. Great advice for anyone adopting EDM or anything else for that matter.

Share:  

Posted by James Taylor at 7:52 AM | Comments (0)

A Rule (or even many rules) does not a decision make

David Straus wrote a nice article in Business Integration Journal this month - A Rule Does Not a Decision Make

"Rarely is a single business rule the basis for making any decision. More often, many rules interact to form a decision. An underlying concept in a decision architecture is that business decisions are the atomic unit we should be focused on, not the rules. "

Absolutely. Given the title of this blog is "Enterprise Decision Management" you might expect me to agree with this and sure enough I do. It has to be said, however, that one of the attractions of using a business rules management system with a structured rule repository is that you can re-use rules effectively between decisions. Oracle even uses the phrase "decision service" which maps pretty well to this concept. He goes on to talk about complexity in decisions

"Organizations want to make decisions that are far more sophisticated than they’re able to make using people to make decisions manually, or using “coding” to automate. These decisions are made up of hundreds of rules. Banks would minimally like to make consistent decisions on several factors associated with a decision such as a customer request to refund overdraft fees"

Well this gets more interesting. While it is certainly true that I know customers who use Blaze Advisor to manage very complex decisions with just rules (10s or 100s of thousands of them) his examples strike me as classic examples of the limit of rules as an approach and of the point at which analytics need to be added. Take the examples he uses:

• Does this person have a history of overdrafts (how often and over what time period)?
• Does this person make money for us (i.e., large average balance in a non-interest-bearing account)?

Now these are classic origination questions, that is to say rules in deciding whether to "originate" a credit product for someone. Many years of experience in Originations tells us that if you try and write more and more rules to manage the process, you end up excluding almost everyone. The rules are simply too "atomic". It does not matter if you can make them complete and consistency as David discusses, you need to balance them more intelligently. This is the essence of analytics - managing uncertainty and complexity of sources.

In the case David is examining what we need to do is assess two things that are uncertain - how much money are we likely to make from this person over time (something that involves retention trends, cross-sell potential, profitability of individual products etc) and the risk of bad debt (a complex intersection of things, often represented by the FICO score). Rather than try and write more and more rules to address this, it is much more effective to use data mining and predictive analytic techniques to build a predictive model for each of these such as a scorecard. This kind of model allows for potentially complex trade offs between factors while being statistically valid. A predictive model like this can then be integrated into the rules, at least in products like Blaze Advisor that understand what a predictive model is, and then used along with rules to make the decision. Egg is an example of a company that does this with Blaze Advisor and Capstone Decision Accelerator is a product Fair Isaac has developed, using Blaze Advisor and the FICO score and other predictive models, to handle this kind of situation.

EDM - focus on decisions but use rules and analytics as necessary.

Share:  

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

April 18, 2006

Technorati update

Working through some Technorati stuff and need to put this Technorati Profile link into a post.

Sorry about that....

Share:  

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

April 17, 2006

Decision-Support or Decision Automation (or both)

An old colleague of mine, John Parkinson (hi John) writes in CIO Insight and recently posted this article on Decision-Support Systems: Lessons from the Military. I remember John telling me this story once before years ago and his column on it made me think about the differences between decision-support and decision-automation.

Using the example of a military flight simulator - aimed as he puts it at "a tiny proportion of the human ability spectrum and extraordinarily well-educated and capable people" - he shows how you can create situations where "the next piece of information - even if it's useful or even vital - can degrade decision-making". It seems to me that this is often a problem in the process most organizations follow when deciding how to solve a problem using their data. All too often the question asked is "how can I give this person more or better data" when, as John points out, this may well not help. Instead I would argue that the right question is "how does the organization make better decisions". The answer to this broader question might be more data, or data analyzed differently, or it might be some change to the whole decision process.

John goes on to say (among other things) "recording, analyzing and replaying decisions helps improve decision-making capability". This is, to my mind, not only completely true but also a great driver for using business rules management systems to automate decisions. One of the great features of a business rules management system is that, because rules are atomic and either fire (take the defined action) or do not, each decision instance can log exactly which rules fired. These rule logs are definitive and can be readily analyzed, making improving the decision something that can be made more systematic.

John also says that "automation of routine decisions helps almost all the time" and points out that any automated decision needs to have ways to track that it is not going well or is trending poorly. It is also pretty clear that it is worth having some percentage of the cases where automation does not attempt to come to a conclusion so much as refer the decision for manual review, hopefully with some strong context as to why it is being referred. One of the ways in which the inclusion of predictive analytics into rules-based decisioning systems really helps is in addressing ambiguity - where there is uncertainty. When I am trying to decide about an insurance policy there is uncertainty as to how risky a driver you are. When I am trying to decide which cross-sell offer to make there is uncertainty about how you will respond. Building predictive models to give you some assessment of how likely these things are can reduce the number of cases when you must defer to manual decision-making.

Decision-support is different from decision-automation but uses many of the same skills and approaches. They are highly complementary - they blur together for most of the really interesting problems.

Share:  

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

Enterprise Decision Management and the Payments process

Interesting article on the payments process in Bank Technology News - Collapsing the Payments Process for an Enterprise-Wide View of the Business. One of the key approaches identified is ",Process automation and support driven by a dynamic rules engine", with which I agree completely. There were some quotes that I thought were particularly apropos for illustrating why Enterprise Decision Management is a perfect fit for this view of payments.

"elevating payments processing from a back-office function organized by distinct lines of business ... into a strategic business that needs to be managed with an enterprise-wide view"

Absolutely, and this is a key tenet of Enterprise Decision Management - stop taking decisions in silos or lines of business and start taking decisions across the enterprise. Treat decisions, like payment decisions, as corporate assets and manage them as such.

"The benefits of an enterprise-wide approach are many and include the ability to more easily meet regulatory requirements... to provide near real-time positioning for settling accounts throughout the day rather than just at end of day, to decrease costs associated with running multiple payment platforms, and to improve research and exception processing."

The use of business rules to manage decisions has great value when it comes to demonstrating compliance, especially with layers of numerous rules as in payments. I won't repeat myself here as there's lots more on the blog under Compliance. Moving to real-time from batch decision-making is another reason people automate these kinds of decisions and the automation of decisions like this also enables an organization to move to 24x7 operation as decisions can be taken anytime. The use of a central decisioning platform, especially one like Blaze Advisor that supports multiple platforms such as .NET, COBOL and Java, can really help with this centralized, managed, cheaper approach. Lastly the use of rules makes exception handling and research into decision processes easier - rules are easy to log and the logs can then be analyzed or passed on to those handling the exceptions.

"key to achieving an enterprise-wide view o