Introduction
Business analysts are at the sharp end of one of the great challenges of information technology – how to build the systems organizations need. And further, how to do so quickly and cheaply and in a way that will allow those systems to be readily adapted to rapidly changing business environments. At the same time, organizations are demanding more sophisticated systems – the “dumb” systems of yesteryear are no longer enough. Now customers demand self-service, systems must support mobile devices, organizations want to improve their operations by understanding the ever increasing amount of data they have and regulators want to peer into systems to make sure they are compliant. Business analysts need new approaches that will make it easier to meet these challenges.
Focusing on Decisions
Developing these new systems requires a focus on decisions – the decisions that the systems need to make. Pricing decisions, eligibility decisions, approvals and more must be built into systems. Only then can these systems support straight through processing without having to wait for manual review, allow customers to serve themselves without being constantly referred to supervisors, and support mobile devices whose form factors require more focused, action-oriented applications. Decisions are also what regulators regulate and what data can improve (if it is applied right). Automating decisions makes systems smarter.
The most effective approach for adding decisions to applications is to define and manage them explicitly. This approach is known as Enterprise Decision Management (EDM) . EDM manages and improves the decisions that create value in your business by making your decisions explicit, using business rules to define them so they can be changed easily for maximum agility, and by integrating them with business intelligence and data mining to put your data to work. By applying EDM and focusing on the decisions that create value, business analysts can create smarter systems that more directly tie to business objectives.
Benefits
Combing enterprise decision management with other requirements techniques has a number of advantages. Use cases have always had decision points in them. Applying EDM externalizes the definition of the business decisions behind these decision points. This keeps the use cases simple and clean while allowing the specifics of the decision to be defined and managed. Strong, rules-based definition of these decisions means that the final system can replace embedded decision points with true Decision Services – components that make decisions. Simpler, more concise use cases are the result.
Making these decisions stand out from other kinds of requirements helps in other ways too. It enables requirements for performance, compliance and audit to be mapped specifically to the decisions involved rather than being applied loosely to the whole system. Separately managed decisions can be mapped to Key Performance Indicators and other business objectives so that the analyst can specify exactly how improvements to or problems with that decision will impact the business.
Specifying Decisions
These decisions must still be specified, however. Decisions are fundamentally rules-driven with the rules describing how the decision is made. Decisions require operational data to act on but they often also require an understanding of historical data because that historical data informs the decision. Neither business rules nor historical data analysis, using data mining and other analytic techniques, lend themselves to specification as requirements.
Trying to represent decisions in standard requirements documents often results in convoluted language, complex tables, or other representations of those rules. This approach embeds the rules within the requirements document and that leads to the rules being validated, verified, implemented, and tested within the greater context of the requirements. Business rules are often reused across multiple decisions, however, and decisions are reused across use cases so this rapidly creates duplication. Keeping business rules separate and mapping them to use cases through the decision points in those use cases enables single source information – the business rules list or repository.
The rules behind the decisions should not be managed the way requirements are managed. After all, requirements define what the system must do to meet the users’ needs, prioritize capabilities, establish “acceptance” criteria and articulate intent. Business rules are the criteria for making decisions and thus controlling behavior. They specify the application of laws and regulation, the company policy to be enforced, best practices and calculations. Using decisions to connect them to other requirements helps you manage them. After all, rules change due to different drivers like external regulations or market conditions and so rules change independently of requirements. Keeping business rules specified in a clean declarative style also allows rules to be analyzed for accuracy and completeness and simplifies approval and change management. This separation allows business users to focus on the rules that define their business not the requirements about design or performance, integration etc.
“The major difference between developing systems 20 years ago and doing it today is that change is much more pervasive now. Changes to business processes and rules, user personnel, and technology make application development seem like trying to land a Frisbee on the head of a wild dog.”
“Use cases…cannot portray all the subtleties of how a business is run. For this, we need business rules” (Kulak & Guiney, 2003)
The need for historical data analysis in decisions means that data mining and analytic requirements must be specified for decisions. Like rules, these do not lend themselves to specification in the usual requirements documentation. One approach is to identify data mining as a source for rules. For instance, there may be a set of rules that come from data mining showing which products are sold together or how a customer segment is defined. This becomes part of the rules specification. Another approach is to consider the additional data being created by data mining or analytic techniques as part of the information required by a decision. For instance, a customer churn risk score might be required and this would be built using predictive analytic techniques and recorded as part of the data set being used to make a decision. Linking these needs to the decision and to the rules in that decision makes it easier to incorporate and manage data mining and analytics.
Changes
Companies adopting EDM make a couple of fairly straightforward changes to how they specify systems. First they use a process called Decision Discovery to find the operational decisions that matter to their business, that drive results. Decision Discovery finds the operational decisions that drive use cases and externalizes them. These decisions are those required to make the use cases execute effectively. Finding these decisions, mapping them to organizational objectives and performance metrics and understanding their impact on the business is critical. Decisions become part of the specification.
The next step is to specify how these decisions are made so that Decision Services can be built. A Decision Service can be defined as a self-contained, callable component with a view of all conditions and actions that need to be considered to make an operational business decision. More simply, it’s a component or service that answers a business question for other services. Business rules are the core building block of decision services and are reused and managed by the business. Tribal knowledge, expertise, regulations and policies are all represented as business rules. Applying data mining and other analytical insights systematically to decision services allows these insights to be applied not just to broad statements or corporate strategies, but deep down into the day to day operations of your business processes. These rules and analytic models are managed independently but mapped to the decisions.
Example
As an example, a use case might include a decision “Approve Claim?” Rather than describing how to approve the clam in the use case description, the decision should be recorded as a separate artifact. This Claim Approval decision can be mapped to KPIs like Cost of Claims or Fraud Detected and requirements for performance or compliance with regulations can be mapped to the decision.
The decision is made by following a set of rules. Some of these rules will be unique to this decision (such as maximums for approval without referral to a supervisor) but others will be used elsewhere also (such as the amount of information required about a claimant). You could create a series of branches in the use case to encode this decision but it is likely to become unwieldy quickly. You could embed a decision tree or other description into a requirements document. However, you still are applying the (potentially) heavyweight requirements approval and validation process to this decision tree. You are also asking your developers to review this decision tree and determine how to implement it. A great developer will see when it makes sense to abstract these decisions from the code, and a less-great developer will embed them. In either situation, you’re asking your developer to spend time thinking about this abstraction - and thinking about how mutable the particular decisions are.
As an analyst, you are better informed and can document the decision as a single decision in the requirements document and referencing enumerated business rules in a business rule list or repository mapped to the decision. It is also easier to review the rules and validate them when they are isolated. Business people who don’t have backgrounds designing software find it easier to review the rules when they are presented in the context of a decision - and it is easier to grab the context of the decision from a simpler use case. When it comes time to make changes, it is also an easier process to approve those changes when you are only updating and reviewing the business rules - and not a broader requirements document. The potential for an analytically-derived risk model (Risk of fraud, for instance) as part of the decision can also be recorded allowing for more sophisticated decisions to be defined without over complicating the main requirements process.
Conclusion
Companies increasingly need systems that make decisions, and good ones, without manual intervention. They must support self-service, straight through processing and mobile devices. Specifying how to automate a decision using a traditional requirements approach is not ideal as it makes it hard to see the decision separate from the rest of the requirements, hard to specify the requirements for the decision itself and hard to manage the often radically different update cycles for decisions. Externalizing decisions, mapping them to separately managed business rules, specifying the KPIs and requirements of those decisions and linking them to data mining and analytic insight will allow business analysts to design smarter systems while retaining the agility that is increasingly essential.
Author: James Taylor is CEO of Decision Management Solutions and one of the leading experts in decision management. James works with clients to develop effective technology solutions to improve business performance. He has over 20 years experience in developing software and is the foremost thinker and writer on decision management.
James can be reached at [email protected].