BusinessWeek had an interesting article in December about the growth of Tesco, a British grocery chain, and on its use of data mining as a competitive weapon. Here’s a quote: Analysts say that Tesco’s big advantage over major international rivals, which also include Germany’s Aldi and Lidl, is its unrivaled ability to manage vast reams [...]
ebizQ
With the business world in a state of flux and everyone worried about what might happen next, and how they might respond to it, scenario testing (and its compatriot, stress testing) should be top of mind for executives. They should be thinking about different scenarios, testing out how those scenarios would effect their business and trying out various alternatives. On the risk side they should be using this kind of scenario planning to stress their assumptions – stress testing – to see how their financial reserves would cope with the various alternatives.
For too many executives, however, this kind of testing is done only at the aggregate level and done largely (if not completely) in Excel. I have nothing against Excel but this is clearly not really acceptable. Good scenario or stress testing should consider how customers, products, suppliers, locations will be impacted by the scenario at a granular level and then present rolled-up results, not simply attempt to model some averages or totals. Similarly, if executives want to develop alternative scenarios that would be effective in certain possible futures then they need to test those scenarios against actual transactions, actual customers, to see if they work.
Companies that have adopted decision management have the infrastructure to manage this. Decision management brings the crucial decisions – choices of actions – into the open and makes them explicit. Scenarios can be developed for these decisions and tested against real data. The results can be compared against what happened, or against alternative scenarios to see what would work best. Different assumptions can easily be fed into the decisions to see what impact those assumptions have and stress testing or scenario development conducted based on the results. Decision management makes all this possible. It’s still work, but it is much less work and the results can be much more precise and grounded in real decisions.
A growth in scenario management was one of my predictions for 2009 and Jim Sinur wrote a nice piece on this too – Scenario Planning is No Longer Optional.
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.
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…
