I thought it would be fun to highlight my 20 most popular posts from the last couple of years so here goes:

1. Keeping Predictive Analytics and BI on separate tracks
   
2. If IT wants to alter outcomes, it needs to automate decisions
   
3. Business rules, events and processes
   
4. Getting a competitive advantage from your data
   
5. Achieving Agility - some notes after Gartner
   
6. Introducing business decision management
   
7. Here's a way to put analytic solutions in the driving seat
   
8. Decision Technologies and Active Data Warehousing
   
9. SOA and Business Rules, perfect together
   
10. Business rules, routing rules, event rules
    
11. Decision Services
    
12. Decision management is critical to event driven architecture
    
13. Decision Management - another way to get the business to care about SOA
    
14. Marketing Analytics in a Post-Web 2.0 World
    
15. Little known ways to improve customer experience
    
16. More on rules and event processing
    
17. Business rules, desktops and knowledge buses
    
18. If dashboards are the end game, kill me now...
    
19. COBIT, SOX, compliance and business rules
    
20. Call for Presentations - the new EDM Summit
    

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Intelligence • Business Process Management • Business Process Outsourcing • Business Rules • Compliance • Decision Technologies • Event Processing • Innovation • Legacy Modernization • Predictive Analytics • Requirements • SOA | Permalink | Comments (0) | TrackBacks (0)

• How are you integrating business rules and analytics?
• How are you adding intelligence to your business processes?
• How are you putting analytics to work in your operational systems?
• How, in other words, are you using Enterprise Decision Management (EDM) to innovate your business? Your colleagues and peers want to know.

We invite you to present at the Enterprise Decision Management (EDM) Summit OCTOBER 26-30, 2008 -- ORLANDO, FL  

Join us this year to share how the technologies and approaches of Enterprise Decision Management (EDM) have helped your organization deliver agility while managing risk, focusing on customers, or demonstrating compliance. Whether you call this Business Decision Management or Customer Decision Management or just Decision Management, we want to hear from you. The EDM Summit brings together managers, practitioners and vendors to talk about what works and to provide attendees with a host of practical ideas they can put to use in their own companies. These practical ideas don’t come from us, they come from you.

Most of all, we want real-life case studies. We want to hear what really happened, what worked and what did not, from the actual people who undertook them. Whether you want to show how you got started or how you have learned from experience, whether you want to talk about technology, people or methodology we want real-life cases. If you are a consultant or vendor, the best way to be accepted is to co-present with someone from your client’s organization. Real experience, not company positioning or marketing buzzwords, is what it takes to be selected.

Particular areas of interest include, but are not limited to ...

• Using decision services with BPM or SOA to put intelligence into composite applications
• Using business rules and analytics or data mining in combination
• Implementing adaptive control and champion/challenger testing
• The impact of the technologies and approaches of EDM on the software development life cycle

 Your presentation ideas are welcome in any of our mainstay topic areas, including ...

• Business Rule Management Systems and Engines
• Data Mining and Predictive Analytics Technologies
• Techniques and Methodologies for Data Mining and Predictive Analytics
• Decision Services, Business Rules and SOA
• Adaptive Control and Optimization
• Managing Decisions in BPM and SOA
• Moving to BI 2.0 / Operational BI
  
• Event-based Decision Management
• Compliance and Risk Management
• Organizational Change

Not on the list? Tell us about your own unique ideas! Top architect at a mainstream software vendor? Creator of a highly innovative product? We will consider your presentation for our Chief Architect's track. Highly selective. 

We Want to Hear from You ...

We welcome presentation ideas from all! Do you have a business success story? Best practices about how to use decision management technology? Significant progress in applying data mining to operational systems? EDM Summit is THE place to present on experience, proven solutions and new innovations in this exciting area. We bring together companies and experts from diverse industries in a unique and exciting venue to share their experiences. Do you know qualified colleagues who would make great Forum speakers? Click here to forward this message to a friend. Invite them to submit their Presentation Abstract for consideration!

CALL FOR PRESENTATIONS SUBMISSION DEADLINE: March 31, 2008  

To submit your presentation idea ...
Step 1. Please read the Speaker Agreement carefully.

Step 2. Complete the Speaker Abstract Submission Form.
Presenters will receive a full complimentary registration to the Business Rules Forum, including the two co-located conferences Enterprise Decision Management (EDM) Summit and Rules Technology Summit as well as to RulesExpo.

Got a question? Please email us at speakerinfo@businessrulesforum.com 

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Intelligence • Business Process Management • Business Rules • Compliance • Decision Technologies • Event Processing • Predictive Analytics | Permalink | Comments (0) | TrackBacks (0)

Yesterday I saw an interesting article over on TechRepublic - Sanity check: The 10 biggest headaches of 2007 for CIOs and IT managers. It was a nice list and a couple of items struck me as being great justifications for taking a more thoughtful approach to decision management and the technologies of decision management. The two headaches in question were "Alignment between IT and business goals" and "Dealing with compliance". In both cases the author took a different perspective to mine which is that alignment and compliance, especially in combination, are great drivers for adopting decision management.
My perspective on these two issues is that, with companies automating more and more business processes, ensuring alignment and compliance means making sure that what is coded into the processes and services being automated is aligned and compliant. The best way I know for doing this is to focus on the decisions in those processes and to automate those decisions using business rules. Why does this work?

• Decisions, business decisions, are one of the most critical areas where the business and IT must be aligned. Focusing on decisions explicitly is key
• Business rules, being declarative and amenable to business user management, ensure that the decision logic can be developed collaboratively by the business and IT. This helps ensure alignment
• Business rules are easier to check for compliance than code both because those who understand the regulations can read the rules (but probably could not read the code) and because it is very easy to tell which rules executed for which transaction and this makes it much easier to show compliance

Posted by jtaylor in Business Rules • Compliance • Decision Technologies | Permalink | Comments (0) | TrackBacks (0)

<shameless commerce>

As some of you know by now I have been working, with Neil Raden, on a new book. As the files shipped to the printers today I thought I would take the opportunity to shamelessly plug the book here on the blog. The book's premise is that much of today's existing technology has the potential to be "smart enough" to make a big difference to your organization's business and that current business trends are forcing you to build smarter systems. Like this blog, the book discusses how focusing on decisions as distinct opportunities for improvement, you can use established technologies in a new way to solve problems and create competitive advantage.

You can pre-order it here from Prentice Hall (there is even a blog discount coupon code TAYLOR7962) or from amazon.com here (amazon.com has not yet decided what price it will charge).

The book has a companion site too - http://www.smartenoughsystems.com where you can subscribe to news about the book/authors and read the testimonials we got. Over time we will add more useful links to the site.

If you are not yet convinced that you need to read the book, why not try the digital shortcut "Why you Need Smart Enough Systems". You can buy it online from Prentice Hall  for less than $5! If you need to be convinced that you need to use decision management to make your systems smart enough to be useful (or if you have colleagues or customers who don't understand why they should apply the techniques we talk about on the blog), you will find this a good read.

</shameless commerce>

Technorati Tags: adaptive control, business rules, data mining, decision, decision automation, decision service, decision service, EDM, enterprise decision management, optimization, predictive analytics, Smart (Enough) Systems, smartenoughsystems

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Intelligence • Business Process Management • Business Process Outsourcing • Business Rules • Compliance • Decision Technologies • Event Processing • Innovation • Legacy Modernization • Predictive Analytics • SOA | Permalink | Comments (0) | TrackBacks (0)

Hugh Taylor (no relation) has just had a great article on Agile Compliance published by Align. Not only am I quoted in it, always a sure sign of a top-flight article, it makes some great points about delivering agility in an era of compliance. You should read the article if you work in an industry with compliance challenges.

Hugh talks about a McKinsey study from 2006 (blogged about here) that discussed agility and showed that business executives thought agility was important but did not see how IT helped. Now, like Hugh, I believe that IT must become an enabler for agility while still ensuring systems are compliant. Hugh recommends an SOA platform, as do I, for this but I would explicitly recommend using business process and business rules for compliance. Part of the reason for this is the need for business and IT alignment (tricky thanks to the different perspectives of IT and the business).

Hugh talks about strategic, operational and functional agility and I believe that both operational and functional agility require decision automation because your systems are your business in a very real way these days. If you cannot change the systems, and do so faster than your competitors, you will be in trouble.

I have blogged and written on this topic a fair bit including this piece on business agility in regulated industries, this one on self regulation by companies, another on SOA and decision automation and finally some notes on Gartner's view on agility.

Business rules make you more, not less, flexible

I reviewed Hugh's book, The Joy of Sox, here. It's good.

Technorati Tags: BPMS, BRMS, business agility, business process management, business rules, Hugh Taylor, SOA, Joy of Sox

Posted by jtaylor in Business Agility • Business Process Management • Business Rules • Compliance • Decision Technologies • SOA | Permalink | Comments (0) | TrackBacks (0)

I saw this nice piece by David Kelly on Managing IT Risk and it prompted me to think about decision management in a risk context.

For instance, David says:

Compliance is a risk that has received a huge amount of attention over the past few years, as organizations strive to meet new regulatory requirements and enable faster, more efficient audits of all types of business processes.

An important part of building a risk mitigation plan is to understand the impact of the different types of events or risks that an organization can encounter.

IT risk management plans that provide disaster recovery, business continuity, as well as assurance that an organization is equipped to successful handle a wide range of potential problems.

Posted by jtaylor in Business Agility • Business Rules • Compliance • Decision Technologies • Legacy Modernization • Predictive Analytics | Permalink | Comments (0) | TrackBacks (0)

I got a note from the folks at ZapThink about an article in SAP Netweaver magazine called "5 Business Reasons to Service-Orient". The 5 reasons given are

"reduced integration costs, automated business-to-business interaction, easier regulatory compliance, user empowerment, and the ability to react to change more quickly"

The article goes on to use an illustration of the way "Carla" works to show this. In fact Carla would only really become more effective if the company not only adopted a service-oriented approach but also automnated some key decisions. Let's consider the scenario:

"Carla is a call-center representative for a bank. She takes calls from banking customers and accesses various systems on her computer to help address each customer’s question or concern"
Clearly Carla is being asked to make decisions about customer treatment all day

"Despite her best efforts, Carla occasionally makes mistakes that she or another call-center representative have to fix later"
Some of these are probably data entry errors and so on but others will be decision errors - refunding something she should not, allowing an account that is not allowed, failing to flag a suspicious transaction, using the wrong pricing model etc.

"Although her boss has repeatedly told her that an important part of her job is advising customers about products they might be interested in, she has a difficult time understanding which products are right for each customer."
Hardly surprising given the number of products offered by a typical bank (which have all the signs of a classic "Long Tail" business)

"After her bank implements SOA, however, Carla’s daily life becomes much simpler...Now, she can spend less time on each call, and information about her customers is at her fingertips. She can identify at a glance which of the bank’s products will be of most interest to the customer, leading to increased sales for the bank and a bigger bonus for her. "
Well perhaps but probably not. Simply having the information at her fingertips won't necessarily help her pick the right product/cross-sell/up-sell from the hundreds available (one major bank recently launched 300 new credit products in a month, for instance). To do this she would need to combine not just the data but predictive insight from the data (this customer is likely to accept this kind of offer) as well as a bunch of regulatory and policy rules in the context of a strategy she cannot know in detail. Ain't gonna happen. The reality is that unless this kind of decision-making is automated in a way that leverages the insight and enforces the rules and gives her recommended actions to take, she it not much better off.

"Furthermore, as various business changes work their way into Carla’s inbox, she can make adjustments quickly and efficiently. Maybe it’s a new marketing campaign followed by a regulatory change, or maybe a new product the bank wants to promote. Service-oriented tools are so powerful, flexible, and easy-to-use that Carla can take advantage of them to do her job regardless of the changes her boss throws at her."
Now why on earth would you want to email Carla new marketing campaign information, new product information or new regulations? Email? She could get dozens of emails a day on these topics and they would likely be buried in hundreds of work ones. There would also be no way for her to tell which ones replaced which other ones and no way for her management to check that they did not contradict each other. And what if the new marketing campaign was something like "offer this new high profit, high risk product only to customers who are not currently profitable and have a risk profile of such and such"? How is she going to do that risk assessment? What if the regulation was BASEL II and meant she had to make decisions based on an updated credit risk model or if the FBI was sending new warnings out about money laundering that she was meant to enforce? Would you really want to tell all these regulators that you were enforcing these regulations appropriately and that you knew you were because "we sent an email to everyone telling them"? Don't think so...

The reality is that for many businesses that are only going to get better regulatory compliance, user empowerment and business agility from SOA if they also think about automating critical decisions in a way that allows users (internal users or external customers) to work without having to constantly refer business decisions to someone and if the way they implement these decisions supports both rapid change (which means business user change not IT change) and regulatory compliance (you can prove to the regulators that you are doing it right). This means business rules as the basis for decision automation and predictive analytics to bring insight to bear on these decisions.

For a couple of other examples of how decision automation can improve a bank, check out this banking story and this one on using decisioning to build the bank of the future.

There's more on regulatory compliance, BASEL II, money laundering, Sarbanes-Oxley and business agility on my other blog also.

Technorati Tags: analytics, BRE, BRMS, business agility, business rules, compliance, customer insight, decision automation, long tail, predictive analytics, Sarbanes-Oxley, SOA, SOX, Netweaver, ZapThink

Posted by jtaylor in Business Agility • Business Rules • Compliance • Decision Technologies • Predictive Analytics • SOA | Permalink | Comments (0) | TrackBacks (0)

I saw an interesting article by Jim Coleman of Appian in Business Integration Journal today - the article is not online yet but here's a link to the magazine - called "Making the Case for Process-Based, Sarbanes-Oxley Compliance". Jim outlines how you can use a BPMS to support a robust SOX compliance approach. I think he understates the potential for a business rules management system or BRMS to also be part of the solution. Let's consider some scenarios:

• If I have a decision, say pricing a product, that is covered by the compliance rules why take it manually and then automate the process of checking it was taken consistently? Instead you could automate the pricing engine using business rules and a BRMS and then compliance would consist of showing the rules used for most decisions and manually tracking just those exceptions referred to people.
• If I have a service in my process that has to be reviewed for compliance but which needs to change often, I could use a business rules approach to automate that service and then it would be much easier to show compliance (thanks to the declarative and business-friendly approach supported by a BRMS) and, because changes to rules are more manageable and trackable, easier to show ongoing compliance even as the service changed.
• If I have multiple systems being checked for compliance of the same action, perhaps I should use a decision service approach to automate the decision once, using a BRMS, and sharing that service across my architecture. Then I would only need to show that the service was compliant, not every application, and this would be easier thanks to rules compliance-friendly nature.

Automating decisions, especially using a BRMS, can be very beneficial when worrying about compliance. A BPMS can too, but the combination might be most effective. There's a great book called "The Joy of SOX" that I reviewed here by Hugh Taylor. Hugh and I also did a webinar on agile compliance with CMP. I have also written an article about how to use BPMS and BRMS together for compliance here and there is a section on compliance on my other blog.

Additional note - The Joy of SOX was excerpted by ebizQ a little while ago and you can read the excerpt here

Technorati Tags: BPMS, BRE, BRMS, business rules, compliance, decision automation, decision service, SOA, SOX, Sarbanes-Oxley

Posted by jtaylor in Business Agility • Business Rules • Compliance • SOA | Permalink | Comments (0) | TrackBacks (1)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Next session was Barbara von Halle (who occasionally blogs on my other blog) on The Vision for BRS: What You Need to Know In 2006

Barb starts by pointing out that rules can be developed, even though nothing has been defined by asking about baseball. She points out that a phrase like "3 strikes and your out" implies all sorts of things like what a "strike" is, who this rules applies to etc etc. She then walks through the example to show how you harvest rules e.g. all the rules for a batter being out, and that although baseball has a very complete and consistent rules most businesses will have contradictions and omissions. The end of the process should be a complete understanding of how the business operates.She goes on to talk about a recent KPI study that found 5 motivations for business rules:

• Agility (see the blog section on business agility)
• Knowledge Retention
• Compliance (see the section on compliance)
• Consistent Decisions
• (After the fact) A stronger Business-IT partnership

and four approaches to using business rules which she illustrated with some great examples.

• Business rules harvesting and then input to the SDLC. Often by mapping use cases to business rules as described here
• Business rules harvesting and then input them into a Business Rules Management System
  A case study for the first two of these found that some 70% of the rules were "wrong" - the code ran wrong and was worked around, the code did what was intended but there was a mistake.
• Business rules harvesting from legacy systems for legacy modernization (see this section on legacy modernization)
  She noted here that thousands of rules found in the code for one client mapped to just 150 "real" business rules and that legacy mining is really only a good idea when there is no alternative!
• Business rules harvesting and business transformation by changing just manual processes or by telling IT to make changes
  Can be done very fast to show the value of focusing on rules. The case study for this showed that this worked and helped generate interest in business rules management.

Interestingly some of these involve business and IT and some only require the business. Barb wrapped up this section talking about the Rule Maturity Model and how most companies working towards Agility (level 2) and Consistency (level 3) which require both a focus on business rules and some technology. She also emphasized that rule management can fail on the business side (not the right rules) or technical side (not working right.

Barb has a model of some 10 types of business rules tools. Personally I think this is a little extreme - I would not separate authoring, analysis, testing and execution into 4 tools as I think these are all tightly coupled parts of a real Business Rules Management System. I do think that having a way to manage strategy and map it to rules and a way to map rules back into the requirements process is useful. Rule Mining is clearly a separate tool, as are analytic tools for deriving rules. I might say then that there are four:

• Business rules management system with authoring and repository
• Strategy and process management tool
• Rule Mining tools (code and data mining)
• Rules as requirements management tool

Barb went on to talk a little about how decisions, and rules, can and should be mapped to multiple processes and use cases to emphasize the importance of traceability.

Technorati Tags: agility, BRE, BRMS, Business Rules, legacy modernization, rule maturity model, RMM

Posted by jtaylor in Business Agility • Business Rules • Compliance • Legacy Modernization | Permalink | Comments (2) | TrackBacks (1)

Keith used a similar title in a different post last week - Complying with rules is not the same as working to rule- and it made me think about the phrase "working to rule". Now "work to rule" is defined in the American Heritage Dictionary thus:

"A job action in which employees do no more than the minimum required by the rules of a workplace in order to cause a slowdown."

Clearly this is not a good thing - by following all the rules all the time workers expect to make things go slower rather than better. If "working to rule" is bad then why is it good to build a system that works the rules, enforces them and generally makes sure they are followed? Well at a basic level the automation of rules, so that they can be enforced all the time instead of selectively, is key. A work to rule slows things down because we are in fact intolerant of the time it takes to enforce all the rules. Sometimes this is because the rules are unnecessarily onerous butsometimes it is because we do not like the rules or because we prefer to rely on our own judgment (see "Blink" for more on this topic). So how does enforcing all the rules all the time help? Well it will depend on your situation but examples include:

• The rules will check all data that might be relevant to a decision in a systematic way, even data that does not seem important. If the data could make a difference it will be evaluated. Skipping these rules might speed things up but will contribute to people's tendency to consider too narrow a range of factors.
• One of the ways to "work to rule" identified in Labor Notes is "Never go by memory, check your reference material" and another is "Never use your own judgment—ask!". These are examples where automation of the rules can really help as no-one has to go by their memory (the reference material is checked by the rules) and no-one needs to trust their own judgment too much - see this refund story for an example. After all the people on the front line cannot be expected to have the whole picture nor can they be expected to go through checking everything while a customer waits. Automating the rules can make it easier all round, in contrast to having your staff work to rule.
• Sometimes the rules are designed to ensure a lack of bias - for instance in lending - and you really want to make sure those rules are enforced all the time.

In many ways the fact that "working to rule" means slowing things down explains why you should automate business rules not write them in policy manuals.

Posted by jtaylor in Business Rules • Compliance | Permalink | Comments (2) | TrackBacks (0)

I was recently reading "The Joy of SOX" (reviewed here) and it lead me to read up some on COBIT (Control Objectives for Information and related Technology - produced by the Information Systems Audit and Control Associationor ISACA). COBIT is "a generally applicable and accepted framework for good IT governance and control practices". As I was flicking through this I cam across one particular section. Under "Acquire and Implement" there is a "Manage changes" objective (for those of you following along in the spec this is AI6). This control objective talks about "the business requirement for IT of responding to business requirements in alignment with the business strategy, whilst reducing solution and service delivery defects and rework".

The section goes on to talk about how this means having change procedures, actually following them and measuring things like disruptions and emergency fixes. This is all well and good but it struck me that the details were predicated on all changes requiring IT to write code. Regular readers (Sandy and the other one) will know I don't buy this and that I work with customers who want to go further towards getting business users able to make changes for themselves (like egg for instance). This is not to say that I think you don't need good change control and release/version management when business users are making the change - you do - but that assuming that improving the process by which IT makes changes is only one way to increase agility while retaining control. If you take the approach, as COBIT does, that IT must make all changes to the system then the best you can do is that this process is managed, measured and constantly changed to reflect changing business realities. For me a REALLY mature organization would manage change but putting the people who understand and can best assess the impact of a given change in charge of making it. This means IT making IT changes and the business making business changes.

Don't aim too low.

Posted by jtaylor in Business Agility • Business Rules • Compliance | Permalink | Comments (2) | TrackBacks (0)

Reading Sandy's blog, as I always do, I saw her mention of this Gartner podcast. This made me think about decision management in insurance so I though I would write some more about it.

Insurance has seen a huge growth recently in the move to adopt a decision automation approach. the reason for this is quite simple - insurance people think in decision-centric terms. They recognize that the underwriting decision, pricing decision, claim payment decision and so on are key to profitability. In addition they are trying to increase the number of transactions that can be managed "straight through" and this means automating these decisions. To make these decisions well, and automate them in the process, insurers are adopting two key technologies in combination (as noted in the podcast) - business rules and predictive analytics. The combination of these is known (to some at least) as Enterprise Decision Management.

The technology helps insurers solve a number of problems:

• Collecting the right data the first time is hard because different data is required depending on the circumstances and so as data is entered it changes the remaining data required. It is not unusual to go back and forth multiple times to capture the required data - costly and time consuming. Rules-driven user interfaces, taking advantage of smart forms and AJAX combined with automation of the decision help ensure this is "once and done".
• The decisions are heavily regulated and so not only must each decision follow a large number of guidelines and policies, it must also be possible to show how the decisions taken conformed if/when a regulator asks. To make things more complicated, these regulations are often different by state and country. Business rules technology allows this to be managed and then reported on.
• Tiering and segmentation are key to pricing and risk management. As this has become more and more sophisticated and as more and more data is available it has become impossible for an individual to consider all aspects in a way that allows fine-grained segmentation. Predictive analytic models can automate this complex risk assessment and allow for much finer-grained decisions.

These problems are often found in less decision-centric industries and these are adopting the technology more slowly. It's a pity as the insurance industry, not typically an early adopter, is really showing the benefits of automating these key decisions.

There is more on automating decisions in insurance on my other blog where I also posted on the value and usage of location intelligence.

Posted by jtaylor in Business Rules • Compliance • Decision Technologies • Predictive Analytics | Permalink | Comments (2) | TrackBacks (0)

Interesting post by Ronan over on his blog - Governments and SOA. One quote in particular caught my eye - "It's about ensuring that our organisations can change to be able to deliver change".

There is a growing interest in using business rules, often in an SOA environment, amongst government agencies for precisely this reason. One example with which I am familiar is the California Department of Motor Vehicles - desribed in more detail here on my other blog - but there are many others such as a European tax authority using rules to process returns, border agencies automating screening rules, benefit eligibility portals, permit validation and so on. What these government examples have in common is not just being adaptive to change but also that one of the drivers of change is regulation.

Business rules are a particularly effective tool when automating regulated decisions. Not only do business rules management systems make it easier to develop and evolve the business rules concerned, they make it much easier to demonstrate compliance with those rules. Every transaction fires (or does not fire) a very explicit set of rules. This can be logged and used to track exactly why each transaction was decided in a particular way. It is easy for lawyers and other experts, who don't have programming skills necessarily, to review and even write the business rules. Most moden rules environments allow the rules to be packaged and deployed to a variety of platforms, including SOA-based ones, and to be integrated with ESBs. This service packaging gives one level of reuse but rules and rulesets can be reused across services also, adding to the reusability delivered by business rules. The automatic deployment capability of leading platforms also means that rules can be changed once, often by a business user, checked for compliance by non programmers and then deployed to potentially many services or platforms to ensure that all systems now use the new rules.

Government agencies are learning what regulated industries like banking and insurance have known for a while - business rules prepares you for "change time" better than anything especially when the changes can come from legislators and courts.

Posted by jtaylor in Business Agility • Business Rules • Compliance • SOA | Permalink | Comments (0) | TrackBacks (1)

Most of you will have seen recent news about GEICO being sued for discrimination - Blacks Sue GEICO For Race Discrimination In Auto Insurance Rates for example. For those of you who aren't familiar, GEICO is being sued for discrimination on the basis that its use of education and occupation in determining insurance rates means that Blacks are often charged more than whites with the same driving record. I don't want to comment on the case but it does illustrate one of the key reasons why business agility is so key, especially in regulated industries.

Let's say that the suit is successful against GEICO, or even that it looks like it might be. If a company has hard-coded its use of education or occupation or any other property of a customer that has a significantly different distribution between races then it is going to be under the gun for changing its code. All the places in the code where that's used must be found and it must be removed. Statistical analysis must also be done to determine the impact on rates etc. One imagines that anyone continuing to use such measure if and when they were found to be illegal would be doubly exposed.

If, on the other hand, I have coded these potentially regulated rules in a business rules management system so that I have them in one place, managed as a corporate asset and structured to allow those with business/legal expertise to edit them, then I am in a much better place. I can quickly find the rules that are impacted (using repository tools increasingly common in leading products) and change them without any IT involvement before pushing them rapidly through testing and into production. Business agility enabling compliance.

This also illustrates why compliance is not something that can be assumed to run on a legislative schedule. Just because the law changes only slowly or periodically does not mean that a court case cannot force you to change your rules of doing business more or less instantly.

One last thing - you want to make sure that any business rules management system you use let's you control what kinds of things can be used in which rules so that you can make sure not to allow business users to accidentally include checks that are illegal. This requires some kind of templating and edit control approach not just a business rules free-for-all.

I have blogged on similar topics on my EDM Blog a few times - notably here and here, though the second one is mostly a link to an ebizQ article - Is business agility an Oxymoron?

Posted by jtaylor in Business Agility • Compliance | Permalink | Comments (1) | TrackBacks (0)

I read a lot these days about managed IT in one from or another - managed systems, managed processes, managed management and so on. So why manage decisions?

First let's be clear what a "decision" is in this context. A decision, or more precisely a business decision, selects from alternatives, typically to find the one most profitable or appropriate for the organization and/or the customer. To do this various facts or pieces of information about the situation and the participants in it must be considered. Finally an action is taken - decisions are not just about knowledge being added to what is known. Decisions are taken by enterprises at every level – from strategic decisions taken by the CEO to the intensely operational ones taken by customer service representations or store workers. Decision Management is largely an issue with these operational decisions. If we want to automate these kinds of decisions, and we do, then we need to consider Decision Management as a separate discipline, not just part of systems development.

Automating decisions involves embedding know-how into operational systems. Often this know-how is specific to your organization so buying a package has limited value - the package vendor does not know how you like to take decisions. Traditional coding approaches tend to separate the expert from the process - most business experts don't read code very well and so have a hard time editing it or even reviewing it for accuracy.

In regulated industries - and let's face it most industries are more and more regulated these days - compliance is another issue with decisions. Will you be able to show that this decision was taken in a compliant way if you automate it? Do you think the regulators will be able to read that code? Will you be sure exactly which bits of the code executed for each transaction and can you log that?

Decisions also represent one of your key areas for competitive advantage and distinctiveness. In an era of standardized forms and increasingly best-practice focused processes, how you decide things makes a real difference to how you are perceived. If you decide to take on high risk customers (for a price) or to decline certain kinds of requests, these decisions affect how the market sees you. Managing the decision you take interacting with customers is thus key to your market perception.

So operational decisions must be automated differently and can be key to your business. They deserve to be managed as corporate assets and this requires new technologies, new approaches, a new mindset. More on this as the blog continues.

Posted by jtaylor in Business Agility • Compliance • Decision Technologies | Permalink | Comments (0) | TrackBacks (0)