Enterprise Decision Management - a Weblog

(Posted by guest Blogger, Gib Bassett)

Respected technology prognosticators John Rymer and Connie Moore of Forrester Research just published a new paper titled, “The Dynamic Business Applications Imperative” (September 24, 2007, For CIOs). Rymer and Moore envision a new generation of enterprise application that some IT organizations today are cobbling together in order to meet ever changing business, technical and marketplace requirements. The paper is peppered with examples of what they term “Dynamic Business Applications” in use at many household name companies. At the heart of their idea is integration of the “B3 categories” of software � Business Intelligence (BI), Business Process Management (BPM) and Business Rules � that together with Services Oriented Architecture (SOA) will lead to a more agile platform for the mass market composite applications of the future.

There are far too many interesting points to write about here, but some of those I found particularly applicable to Enterprise Decision Management (EDM) were:

• Dynamic Business Applications will always be composite, never monolithic as are often seen today. Decision Services blending rules with analytics meet 2/3 of the required functionality of a Dynamic Business Application, as described in the report.
• The report cites a September 2006 survey of business and IT decision-makers, in which the top two business problems facing enterprise application implementations were “inflexibility limits process changes” and “lack of visibility into process results.” These two concerns mirror recent reports of convergence among the “B3” technologies cited in the report, and reflect the move toward “operational BI” or “operational analytics” by many traditional BI vendors.
• CIOs need a strategy to guide both custom application development and packaged application purchasing that considers Dynamic Business Application requirements. This suggests vendors who can provide applications as well as the tools on which the applications were built stand to benefit most.
• The report concludes with recommendations, including ways of identifying processes in an organization that must be Dynamic Business Applications. Decision Yield is an approach that isolates the highest value processes that can benefit most from decision management. Considering the complexity wrought by rapidly changing applications, it’s not surprising the authors also endorse a strong change management regime to anticipate the governance issues that will arise � again, core concepts in EDM, resolved via an enterprise-wide approach to managing the rules and analytics underpinning operational systems and applications.

I recently blogged about the convergence Rymer and Moore describe, having read it implied and mentioned specifically in several other sources, yet this is one of the most complete and well thought out arguments yet on the probable future of enterprise applications.

(Posted by guest Blogger, Gib Bassett)

Today I read a September 21 Gartner Research note by Gareth Herschel titled, “The Role of Analytics in Adding Value to Business Processes.” As someone expert in analytics more so than Business Process Management (BPM) and Business Rules Management (BRM), Gareth raises some important points to remember when discussing the role of analytics in business processes.

This topic is all the rage right now, but few have raised the points Gareth does. Consider his viewpoint that there are three ways analytics add value to business processes, and the implications of each. The degree of difficulty escalates with each level, culminating in the third dimension where decision makers rely more on data derived facts than gut instincts to affect process performance.

1. Easy - Analytics to remove either high cost or low value steps in a process. Lower cost product replacement over higher cost repair, and fast tracking low risk claims, are examples.
2. Less Easy - Analytics added to a process. Using customer service call history as an input into cross or upsell offers is an example.
3. Hard - Analytics to support the improvement of a step or steps within a process. A retail bank analyzing its marketing offers to determine how results would vary based on different communication scenarios is an example.

Number 3 is considered hardest because it requires admition by a process “owner” that performance data may support a more effective process than personal experience or domain expertise. That’s interesting in light of many Business Intelligence (BI) vendors focusing on providing just these types of analysis, yet they almost universally lack a closed loop back to the operational systems or applications in question. So there’s an inherent latency involved that agile-minded organizations will find unappealing � and yet Gareth notes the agile-minded are key supporters of the easiest of the three dimensions. I see dichotomy here in that the more difficult (and potentially most valuable) approach happens to support the least agility (but it could).

An Enterprise Decision Management (EDM) approach avoids this scenario by serving as the glue between traditional BI and BPM software; rules, policies and analytics can all be managed separately from their execution environments and be as “real time” as required when rendered as SOA-compliant Decision Services. I would also note that an EDM approach to decision management facilitates the coming together of the application developer and BI-sides of an IT organization. This can especially be helpful in light of this closing note by Gareth:

Determining the appropriate combination of analytical techniques, and the different aspects of the process they can support, will become a critical domain skill for business process managers and developers across every organization. In every case, the analysis that is used should become part of the tracking and measurement process to ensure that the analysis and the decisions taken as a result of the analysis are correct.

(By guest Blogger, Gib Bassett)

Today on DMReview.com I read Microsoft announced a new server called “Office PerformancePoint.” Besides thinking that was a really cool sounding name for a piece of technology, the substance behind the release is what really caught my attention.

Like any wave Microsoft rides, a new offering focused on monitoring, measuring and improving business performance signals that EDM as a discipline with technology implications will become increasingly mainstream over the next few years. Consider:

“Office PerformancePoint Server 2007 is built to meet the functional and performance requirements of a large enterprise, but its competitive pricing allows companies of all sizes to use the application broadly throughout the organization. The application is very flexible, allowing businesspeople to build and manage plans, workflows and rules, while IT centrally controls security and information.”

The announcement doesn’t mention business process management (BPM), business rules management (BRM), or other Microsoft server products such as BizTalk specifically, but I would expect soon we will be reading how PerformancePoint has added integration with and/or capabilities associated with these process and operational system oriented technologies. Business Intelligence, BPM and BRM seem to be coming together with the goal of providing real time operational insight to decision makers that can in turn be used to affect changes to operational systems and applications.

I saw this article in Dr Dobbs recently (thanks Mark) - AI: It's OK Again!by Michael Swaine. Michael begins with a discussion of the "seemingly genetic propensity to overpromise" prevalent in AI circles and then gives a nice update on where things stand. Me, I think that most business systems do not need to be intelligent, do not need AI. As you can tell from the title of the book - Smart (Enough) Systems - I believe that proven technology (business rules, predictive analytics, optimization) combined with a focus on decisions (and decision services) and adaptive control can make a typical dumb application smart enough to be useful. To quote a blog posting by Tom Davenport (author of Competing on Analytics):

"By the way, if you want to read more about automated decision systems, don't bother going back to the AI hypesters. Instead, pick up Smart (Enough) Systems: How to Deliver Competitive Advantage by Automating Hidden Decisions"

Technorati Tags: adaptive control, analytics, automated decision making, business rules, competing on analytics, decision management, decision service, micro decisions, optimization, predictive analytics, Smart (Enough) Systems, smartenoughsystems, Tom Davenport

This week I am in Orlando, FL, attending the Gartner BPM Summit. This morning’s keynote speaker was Janelle Hill, Research VP for Gartner. The title of her presentation was “Business Processes: The Foundation Linking Business and IT.” One slide of her presentation, as well as the overall implied though not explicit theme, spurred me to run back to my hotel room between sessions to post this blog. My apologies to Ms. Hill; I extracted the slide in question, and overlaid what I term the “EDM Opportunity Zone.” It is the stripped area below the Productivity Curve and above the Innovation Curve in the attached slide capture.

Recalling my college econ courses where intersecting regions of supply and demand curves always seemed to mean something important, here too I saw something worth noting. This is only my interpretation, but her presentation seemed veiled in the notion that BPM, as a category or market, needed to evolve quickly, lest it become what the general ledger is to an ERP package today. The evolution was about abstracting BPM to a higher level, where innovation and agility defined the space, not simply the management of business processes. The drivers of this change would be global, increasingly competitive markets, real time systems and near perfect information. She mentioned terms like agility and adaptability.

Relating back to the slide, Ms. Hill described how today, most adopters of BPM software derived value from gains in productivity, not innovation. Only after experiencing this benefit over the course of time and via multiple projects, does an organization begin to ponder what added benefits might be derived from managing their business processes more intelligently. This is when innovation becomes the primary benefit of BPM (or whatever the category is termed in the year 2012).

When I saw this slide, my immediate thought was: “why should an organization wait five years before exploring this idea?” EDM is, after all, largely about adding intelligence to business processes, proven in multiple industries, and approaches such as Decision Yield can identify ways to get started with minimal risk. The moral of the story is that any adopter of BPM interested in attaining higher revenues, more profit, increased customer satisfaction, greater shareholder value or other metrics important to their business, should consider this chart. There is no reason to wait, and being among the first to take advantage of this “EDM Opportunity Zone” can have significant long term benefits.

Scott and I have been working on our presentation for Business Rules Forum -Getting It Right. Rules and Requirements in Software (if truth be told he has been working on it while I "help" ) and this has prompted Scott to post two more great posts on rules and requirements:

• Elicitation Techniques for Processes, Rules, and Requirements
• Why Separate Rules from Requirements

This is one of my favorite topics - which is why I am looking forward to giving the speech at the forum with Scott. There's a lot more in the requirements section of the blog.

Technorati Tags: business agility, business rules, Business Rules Forum, requirements, rule management, Scott Sehlhorst, Tyner Blain

This introductory session covered patterns and was a useful recap. A pattern is a reusable solution to a recurring problem. Patternscan beat a high level (architectural pattern) or object oriented design level (design pattern) or indeed at any number of other levels or about other topics. Patterns have a number of elements:

• Name
• Synopsis
• Context/Problem Statement
  Some information about the drivers for this pattern
• Forces
  Why would you use the pattern
• Solution
  An explanation
• Consequences
  Pros and Cons
• Implementation
• Related Patterns
  Patterns combine into Pattern Languages of related patterns.

All of this got me thinking about EDM patterns - what are they? what can I say about them? This is my last post from the conference as I am off home tonight. If you live in the Washington DC or San Diego area, consider coming to the ITARC events there - more at www.iasahome.org.

Technorati Tags: architecture, pattern

Continuing at the IASAITARC event in Atlanta I listened to Don Browning, Principal Architect at Turner Broadcasting, talk about Feature Driven Development.Turner considered XP, SCRUM andFDD sometime ago and found thatFDD fit their waterfall-based mindset. Don started by talking about how problems with project schedules, with poor analysis, QA problems and user acceptance all roll downhill to developers. He had four main points

• Agile (especially FDD) does not mean abandoning architecture
• Agile can work on large projects
• Agile need not be risky "fly by the seat of the pants"
• A solid development methodology bring repeatability and predictability

Agile methodologies are numerous but all match up to the agile manifesto's four concepts. I have written about rules and agile before for InfoQ -Agile Business Rules(Deborah Hartmann also wrote a nice introduction When and How to Formalize Business Rules) and had a conversation with Scott Ambler on this topic. He particularly emphasized the aspect of responding to change because things never get cast in stone. The rate of change in software projects remains very high and drives many project failures (as discussed here). Agile projects make it easier to be successful by delivering smaller projects more often - expectations are managed differently.

Technorati Tags: agile, agility, business agility, business rules, FDD, IASA, ITARC, requirements, SCRUM, SOA, feature driven development, UML, XP

Don started by discussing how FDD is not XP.

• FDD uses UML documentation where XP discourages documentation.
• FDD has an overallsystem model which XP lacks
• XP uses pair programming and test-first where FDD does not

FDD Principles (with my comments)

• Working software is the primary measure of progress
  Yup. Works for me.
• Deliver working software frequently, iterations never last more than 3 weeks (smaller projects use shorter ones, customers do not necessarily get every release)
  With rules you can iterate as often as you like, certainly 3 weeks is very reasonable
• Business people and developers working together
  Well they aren't going to manage that if the only thing they can both look at is a set of code!
• Embrace changing requirements
  Changing requirements is one thing, changing rules are another

FDD has five phases which seem both sensible and a good fit for rules:

1. Develop an overall model (once)
   A domain model to think about the system as a whole. The objects of the system, their interactions.
   Constantly updated during subsequent phases.
2. Build a feature list (once)
   Set of areas, set of activities within that, each step is a feature. User story or lt;actiongt; lt;resultgt; lt;objectgt;
3. Plan by feature (once)
   Rough estimate for each in terms of days from 0.5 to 8 but break up features that estimate at more than that. Find the sequence and assign to iterations.
   Note that some iterations are light to allow for bug resolution and this is built into the schedule
4. Design by feature (many)
   Constant refinement of original domain model.
   Three steps -walk through domain with users, design each feature (could use UML) and validate and review the design.
   Typically 4 days at start of iteration.
5. Build by feature (many)
   Typically 10 days of coding ending with a build before a final day of planning for the next phase.
   Implement classes, code inspection and peer review, promote fully tested code.
   Each step represents an approximate percentage of completeness for a feature

I could not help feeling that using business rules to manage logic in steps 4 and 5 would keep the users more engaged, reduce errors and deliver functionality that could be subsequently evolved by users alone.

Couple of final comments. I like the way FDD separates the architect role on the team from the development manager from the project manager. Don's team found that a change control process became important in later iterations - it wasOK for it to flex a lot early on but not later. I also liked the ability of the FDD model to quickly identify periods when progress stopped.

I am attending(and speaking) at the Atlanta IT Architect Regional Conference hosted by IASA. Angela Yochem of Bank of America gave this initial keynote based on some work IASA has been doing on the skills of IT architects. Angela laid out a model of skills needed based on 5 layers - IT Environment, Design Skills, Quality Attributes, Business-Technology Strategy, Human Dynamics - and four areas - Software, Infrastructure, Business, Information. An enterprise architect, she argues, needs all these skills. She mostly walked through the key issues in this - very useful and insightful but also well documented on the IASA website and so not worth typing here! She wrapped up with some thoughts onskill building:

• On the job (direct assignment or apprenticeship, observation or committees).
• Training (web-based, university, professional, self-study)
• Community Involvement (User groups, IASA)
• Intuition!

She pointed out that different people combine these things in different ways and that all are valid sources. Although more companies are establishing architect career tracks, she also emphasized networking - call people and ask questions, send email and ask questions - build relationships where you can contribute but which also act as a resource for you.

Technorati Tags: architecture, IASA, ITARC

Mike Kavis had a post today "Built to change, Architected to last" in which he discussed a nice new concept from the folks over at BEA - Dynamic Business Applications. These, he says, have four characteristics:

• Built to change (flexible)
• Embody business processes
• Adaptive
• Agile

Business processes require business decisions so making this work is going to require services that embody business decisions - decision services. These services are also, in my experience, one of the most often changed components so thinking about them helps youget set for "change time"and using business rules to write maintainable code ensures that these services deliver on your need for agility not just in terms of being easy to assemble but easy to change also. Mike also talks about the need to "move away from creating reports and move to creating information". I would go further and say you need to change your thinking about BI and think about enabling your systems to make decisions, not just delivering data or even information to people.

While on this thread of agility I also recommend Michael Hugos who published "The three laws of agility" recently.Michael's laws are:

• Agility is now a must have
• Agility requires simple solutions
• Agility requires an understanding of the law of diminishing returns

The compelling need for agility is something Neil and I discussed in Smart (Enough) Systems. In fact the chapter on why you need Smart (Enough) Systems was recently excerpted in the Business Rules Journal, inthree parts - The Need for Smart Enough Systems Part 1, Part 2, Part 3. You can make systems simpler by externalizing the necessary complexity in decision services and if the law of diminishing returns drives you to standard processes, then your unique data andunique decisions help you resist the commoditization of process.

Technorati Tags: agility, business agility, business rules, Business Rules Journal, change time, decision service, EDM, enterprise decision management, Smart (Enough) Systems, smartenoughsystems, dynamic business application

A series of articles and posts caught my eye tonight. First I read Mike Murphy's article on Meeting the Needs of Customer 2.0: Intelligence All Around(DM Review). Mike discussed the issues and difficulties of serving a

new customer, one with high expectations and little patience -"Customer 2.0."

He goes on to say how product quality is no more important than customer experienceto these customers. Mike's focus is on knowledge management and the need to treat knowledgeable customers. Customer 2.0 (great phrase) is not just knowledgeable though, they are also impatient and intolerant of "let me refer you to someone else". Now Mike walks through an example of dealing with this kind of customer. Using the example of call center agents,he makes the point that "agents don't have time to search through too much information". Indeed. In fact they often don't have time to look at any data to make a decision, they need to be presented with the decision itself - "the best answer in the shortest amount of time" to use Mike's phrase. When customer 2.0 is looking for pricing, for a refund, for activation - for a business decision - the agent needs the answer not more information. No matter how "operational" the business intelligence is, it will not really help. And that brings me to the second article, one byBarry Wilderman on Operational Business Intelligence: A New Approach(also DM Review). Barry is focused on the "next horizon for BI" which he says

involves deploying applications along with specific operational solutions and processes, thus enabling "right-time" decision support to a broader base of users at all levels of the organization

Well, perhaps, but is Operational BI an oxymoron?Continuing with our scenario of treating and dealing with customer 2.0, it seems to me that decision support is not going to cut it. Instead the need is for decision automation and decision management. Don't get me wrong, he is right when he says that "even the most finely tuned transaction-based processes come to a stand-still when non-routine events occur". But he misses the fact that the transaction-based process itself must make decisions. This integrates "the transaction world with the analytical world " not "by linking transactions to executives and analysts and then linking the actions they take back into the transaction systems" but by analytically enhancing the transactions themselves. Why have the order entry person recognize the problem, when the system can? Why send someone to a dashboard when rules, enhanced with analytic predictions can be executed more rapidly? If something occurs even somewhat frequently, a decision can and should be built into the system and not rely on an alerted knowledge worker. Barry says:

Automated decision-making functionality ... features proactive notifications with actionable links, role-based dashboards at all levels, and benchmarks and best practices

But surely "automated decision-making" should feature automated actions taken based on policies, regulations, best practices and analytically derived insight? Enterprise decision management, in other words. Which leads me to Seth Godin's post on How to spend $20 million. Seth says:

So yes, treat different customers differently. The more the better, actually. But do it consistently and in a way that your customers respect and understand.

It seems to me that not only does this matter even more for Customer 2.0 (who will find out how others are treated and want to understand why), it means deciding on the right way to treat customers even when they are using self-serviceapplications, websites, IVR systems or talking to an agent. You should use data mining and predictive analytics to create markets of 1. You cannot use operational BI for this and you must be able to control and improve the customer experience. A need for EDM to meet these challenges and use what you know about your customers runs through all three stories, even if the authors cannot see it.

Technorati Tags: BI, BI 2.0, call center, CRM, customer decisions, customer experience, Customer Service, data mining, decision management, EDM, enterprise decision management, extreme personalization, knowledge management, operational BI, personalization, predictive analytics, Seth Godin

I saw this interesting report in the McKinsey Quarterly - Anticipating customer queries in call centers. Thearticle is free if your register and thesummary says:

A telecommunications company trying to optimize the economics of its call centers hesitated to automate its customer interactions because it didn't want to lose revenues from additional sales made by its agents.
Analyzing the potential revenues from each type of inquiry helped the company identify which kinds of calls should be automated and which handled by live agents.

A focus on the decisions in this scenario identifies several distinct areas of applicability for EDM:

• There is the decision as to what options to present to a customer when they call inand related decisions about menu options/referral to a representative
• There is the decision as to which representative or group of representatives to rout specific calls and customers to
• When should up-sell and cross-sell offers be made
• What offer should be made when an offer is appropriate
• What script should a representative use for a given call/customer combination
• Plus all the decisions that a customer might want made like a refund for an error, a change in plan, eligibility for a promotion etc.

EDM involves business rules, analytics and adaptive control (at the most basic level). Each element matters for different reasons in these decisions. Consider:

• Descriptive analytics to segment calls and customers into different, statistically significant groups to assist in routing and treatment
• Predictive analytics to turn data about customers' past behavior into propensity to buy and retention risk predictions (for example) to assist in routing calls to specific groups (sellers v transactors v retainers)
• Rules-based automation of decisions to allow automation of processes (so that customers and call center representatives can use them)
• Rules- and analytics-driven personalization of scripts based on what is known (and predicted) about customers
• Rules-driven menus based on incoming phone identification and matching to customer data (so that customers are only presented with menu options that are relevant)
• Rules and analytics used to identify best next action for a customer (an offer, a suggestion, a request, a freebie)
• Adaptive control used to continually test new approaches against existing ones to ensure that the best approach is being used

Clearly there are more but I hope I have given a flavor. I have blogged before about using EDM to boost call center performanceand about some McKinsey statistics about call centers that likewise show the value of EDM in call centers. I also wrote "Smart-Enough Customer Decisions"for Montgomery Research, based on the material in Smart (Enough) Systems.

Technorati Tags: adaptive control, best next action, business rules, call center, customer decisions, customer experience, Customer Service, EDM, enterprise decision management, predictive analytics, Smart (Enough) Systems, smartenoughsystems, CRM

Nice article on EDM in SDA India based on an interview with a colleague (hi Bill). They messed up the title - it should say that EDM is an APPROACH and not a platform - but the interview makes some key points:

• The 5 dimensions on which you can and should measure decisions (precision, consistency, agility, speed and cost) - the so-called decision yield
• The importance of change management and therefore of readiness, These five posts on my other blog around aspects of readiness might be helpful
• Business and IT collaboration
• Data
• Analytic understanding
• Organizational change
• Operational focus
• The kind of decisions to which EDM applies - micro or operational decisions
• The combination of business rules (FAQ) and predictive analytics (FAQ) that is core to the approach.

For more you could try the EDM FAQor buy Smart (Enough) Systems

Technorati Tags: business rules, decision service, decision yield, EDM, enterprise decision management, micro decisions, operational analytics, predictive analytics, Smart (Enough) Systems, smartenoughsystems

Martin Fowler's bliki had an interesting poston Customer LoyaltySoftwarethat made me think about what a great fit business rules, and enterprise decision management, are for loyalty program management. Applying Martin's patterns and using a business rules approach to handle the automation is a great fit for a number of reasons:

• Loyalty program rules are typically independent and atomic
  Just like business rules in a business rules management system
• Some transactions have multiple consequences
  Each rule that is met has its own actions and those actions can, in turn, trigger more rules. For instance, a transaction might trigger a rule putting someone into a new reward level that means previous transactions now earn bonus points. Inferencing rule engines handle this kind of scenario particularly well.
• Different systems (as Martin noted) need different consequences applied
  The rules for updating multiple systems can easily execute in parallel
• Loyalty rules are dynamic and constantly changing
  Making business rules an even more attractive technology for this. Rules are easier to manage and easier to change
• Many loyalty rules conform to regular templates
  Allowing business users to see simple interfaces for managing their rules
• Analytics add value
  Using past data about the behavior of customers to see if loyalty awards changed behavior allows you to derive the most profitable rules for your loyalty program and focus your efforts on those customers whose behavior will be changed.

I'm sure there are more but that seems like enough reasons. So, if you are building loyalty software, use a business rules management system.

Technorati Tags: analytics, BRMS, business rules, Customer Service, loyalty, predictive analytics, Martin Fowler

Dave Wright had a question for me about the role of EDM in captive finance organizations - that is a finance organization owned by and associated with a particular manufacturer. Dave works for such a company for a large agriculture/construction/landscape manufacturer. Like most captive finance organization their primary purpose is to drive sales of the equipment, though they do make some money on the financing itself. Dave pointed out to me that they already use a rules-based approach to deciding who is eligible for credit and so avoid the need to refer potential customers to a credit officer.With captive finance arms, losses from special programs typically go to the manufacturer although there is an attempt to make money on the financing overall. In this particular case the captive financing group offer customized payment schedules e.g. for farmers based on when they have income. So how can EDM help such an organization innovate?

• Perhaps the most valuable step would be to include analytics in the decision-making process.
  This might include multiple types of analytics - descriptive analytics to segment customers to make more compelling offers (differentiating between those likely to get good financing elsewhere and those not likely to, between customers with a strong brand-preference and those without) andpredictive analytics (predicting credit risk, of course,but also risk of purchasing a competitive product if no financing offered). Descriptive analytics would analytically refine the rules being used so that they were statistically significant and predictive analytics would enhance the data set available for decision making by adding predictions to the raw application data.
• More sophisticated decision automation could allow theblended economics of the deal to be taken into account.
  For instance,if an up-sell product is known to be more profitable then the financing for the up-sell can be made more competitive. Some products might have much higher rates of default or fraud than others and might therefore come with worse financing deals. Certain products might be entry products that often have subsequent purchases and so financing might be made more aggressive on those deals because of the long-term value of such customers. Critical to this process is going to be identifying that each decision (for a customer for a product on a given day) is a unique decision. If "lumpy" sets of decisions are considered instead it will be impossible to add some of this sophistication to the decision-making. Dave talked about repeat customers getting better financing, for instance. But not all repeat customers are equally valuable so the financing decision cannot simply lump all repeat buyers together.
• Newer analytics, like Fair Isaac's Peacock product, do a good job of analyzing purchase patterns even where those patterns extend over time.
  For instance, identifying the subset of buyers of product X who return after a period and buy product Y. Marketing to existing customers can be made much more targeted if this kind of information is available and, again, if the decision to send an offer to a specific customer is considered a unique micro decision (rather than considering sending all existing customers an offer as a sing