We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Blog: James Taylor Subscribe to this blog's RSS feed!

James Taylor

I will use this blog to discuss business challenges and how technologies like analytics, optimization and business rules can meet those challenges.

About the author >

James is the CEO of Decision Management Solutions and works with clients to automate and improve the decisions underpinning their business. James is the leading expert in decision management and a passionate advocate of decisioning technologies – business rules, predictive analytics and data mining. James helps companies develop smarter and more agile processes and systems and has more than 20 years of experience developing software and solutions for clients. He has led decision management efforts for leading companies in insurance, banking, health management and telecommunications. James is a regular keynote speaker and trainer and he wrote Smart (Enough) Systems (Prentice Hall, 2007) with Neil Raden. James is a faculty member of the International Institute for Analytics.

January 2009 Archives

Copyright © 2009 James Taylor. Visit the original article at Using decision management to manage risk.

The Forrester Blog For Information & Knowledge Management Professionals had a nice post on The Growing Importance Of Enterprise Risk Management. One of the key points was this one:

2) They will focus on driving risk management into business decisions. Risk management is not new. Enterprises have internal auditors, Chief Risk Officers, and others responsible for risk identification and management. However most of those I spoke with noted they were not as effective at driving risk management into business decisions, performance metrics were not often compared with risk metrics.

This makes a couple of key points. Firstly it points out that risk management must be driven into every business decision - operationalized if you will. Secondly it correctly points out the importance of performance metrics and risk metrics.

Decision management is critical to managing risk given these two issues. Why?

  1. Decision management uses business rules management to automate operational decisions in Decision Services. This allows the rules (policies, regulations) that have been adopted to manage risk to be pushed into every operational decision in every business process.
  2. These Decision Services are the ideal leverage point for analytics, allowing predictive analytic models (of risk) and the results of data mining to be applied to these same operational decisions.
  3. Decisions can and should be mapped both to risk metrics and to performance metrics. Knowing which decisions impact which performance measures and which risk metrics is essential if you are to manage risk systematically across your business processes.

As organizations start thinking more holistically and systematically about risk they need to also think more systematically about decisions.

This whole issue of mapping decisions to performance measures is one I am going to blog on more.

Posted January 13, 2009 4:25 AM
Permalink | No Comments |
Copyright © 2009 James Taylor. Visit the original article at Great Discount for Predictive Analytics World.

pawhms.jpgI am going to be speaking at Predictive Analytics World in San Francisco next month on From Predictive Analytics to Competing on Decisions on the first day. You can register for the conference here and if you use jamestpaw09 you can get a 15% discount!

I will also be giving a one day workshop after the conference - Taking Action with Analytics: The Decision-Centric Enterprise.

There is a Survey from the organizers and show details are here. The chair of the conferencer, Eric Siegel, wrote a great article on predictive analytics and the show for BI Network that will give you a feel.

Looking for forward to seeing some of you blog readers there!

Posted January 11, 2009 10:49 PM
Permalink | No Comments |
Mike Gualtieri published a nice piece on business rules engine algorithms last July that I wanted to point out to my readers. Mike summarizes the mainstream rules engine algorithms into those that deliver inferencing at run time, those that execute sequentially and those that execute sequentially but have compile-time algorithms to sequence rules correctly. While I have a few comments on Mike's report, I was struck both by its measured tone and a great piece of advice:
Let Authoring Flexibility Drive Your Algorithm Decision
This is key. The extent to which the tool allows you to write authors the way you need to write them, the way your business users need to write them, is what matters. It is the flexibility and agility that business rules give you that is the primary value driver. Pick your vendor based on how the rule editing and management environment will work for you. The capabilities of the vendor's algorithm(s) will impact this but they are just part of the puzzle - the kind of editing and management environment will matter more. Most of the major rule vendors will do a good job on performance, if you use the tools the way they are intended and don't try and force-fit your previous programming experience too much. If you are interested in this topic, buy the report (it's a good one). I would just add a couple of things:
  • I think he under-calls the potential for inferencing engines to run faster than sequential when a very large number of rules exist but where each transaction only fires a tiny percentage (common in regulatory compliance) for instance
  • Some vendors allow different algorithms to be used in different steps in a decision, a useful feature
  • I have never found a Rete user who had trouble recreating a bug. The data in a transaction determines the sequence of execution of rules and the same data/ransaction will reliably drive the same sequence of execution. Sure different data results in a different order of execution but that does not have any impact on recreating a bug
  • I think the ability to integrate predictive analytics with business rules is already bringing new algorithms to bear. A decision tree built using a genetic algorithm might execute the same way any other decision tree does but it shows the results of the new algorithm just the same.

Posted January 9, 2009 11:20 PM
Permalink | No Comments |
Copyright © 2009 James Taylor. Visit the original article at Webinar on the ROI of business rules in decision management.

On January 28, 2009 I am going to be participating in a webinar with InRule on “Quantifying Improved Decision Management: The Value of Rules“. The webinar is free runs for an hour starting at 8am Pacific (11am Eastern). The webinar will discuss decision management and business rules and the kind of ROI people see. It will also introduce a nice little application the InRule folks developed to help you calculate the potential return you would get.

There is also a white paper on the same topic, to which I wrote the foreword, and you can register for that on InRule’s site here.

See you there.

Posted January 8, 2009 9:54 PM
Permalink | No Comments |
Dan Rosanova wrote a piece on The SOA Knowledge Gap that made me think (again) about the value of business rules as a way to manage requirements. Dan points out that
"A unique SOA challenge is its need to bring together SMEs from across the enterprise."
Now this is true but I don't believe that better management of requirements is the answer. In fact what is needed is a way to turn what the SMEs know into something that can be managed in a repository and used to power systems directly. Working with SMEs to create sets of business rules to represent their know-how not only allows this knowledge to be stored in an executable format - reducing the likelihood of implementation error and speeding deployment and maintenance - it also allows each SME or SME group to manage their own rules. A modern Business Rules Management System (BRMS) will allow different users to have different access to rule sets, allowing each set of rules to be managed by those who know them best or those who "own" them. The BRMS can then be used to package up the relevant rules - typically many sets from many SMEs - into a decision service that can be deployed into a service-oriented architecture. Because the SME's can edit the rules directly, business agility is increased because the time from the SME realizing that a change is needed to the time when that change is deployed can be cut dramatically using the rule management features of a typical BRMS. Dan's comments about how to gather the know-how from SMEs are all good, but gathering their know how as requirements and not rules is going to limit the good it can do. I have blogged a lot on this topic but check out these two posts on the difference between requirements and Requirements and on how to fit business rules into a software development lifecycle.

Posted January 8, 2009 3:00 PM
Permalink | No Comments |