InformationWeek

December 22, 1997

Best Policy: Consistency

Competition has led to changes in both IT and business practices. New tools help companies keep internal rules in sync.

By Michael Barnes and Ellen Gottesdiener

growing crisis surrounds the upkeep of business rules and the underlying applications that enforce them. Some experts say the problem could reach epidemic proportions in the coming decade-replacing the year 2000 problem on the IT priority list.

Anyone managing a large organization understands the importance of standard business policies and procedures. Within IT departments, these policies and procedures are referred to as business rules. In most large organizations, they exist in hundreds of computer systems used by thousands of people. They provide a foundation for the complex policies and constraints that govern a business' daily operations.

Can any IT manager or business executive say with certainty that her business rules are totally consistent and accurate? If rules aren't consistent throughout an organization, entire systems-and the business process es they support-can go awry. The results can be devastating revenue losses and crippling lawsuits. Unfortunately, most organizations can't confirm that their business rules are accurate and consistent.

A typical executive cannot simply look at an application and scan all business rules to ensure that they reflect changing business policies. Information systems are unable to give the user an abstracted view of the business policies and assumptions that drive an application's program logic. Business policies are not isolated from the rest of an application's code. Looking at a spreadsheet as a basic example, any business user can easily see the formulas and macros used to make predictions and obtain results. Business rules need this type of metaphor, where each declarative rule is a cell and the process logic or workflow is defined as a macro.

Business rules range from simple business practices, such as when to print a report, to complex processes like calculating sales commissions. Over the past 10 years, the pace of business and the need to change policies because of competitive pressures have required massive changes in IT and business policies. Unfortunately, many organizations still have complex, aging systems filled with outdated business rules. These systems are both difficult to understand and cumbersome to update.

The problem is almost as serious with newer client-server systems. The one advantage with the latter is that the person who wrote the newer application might still be on staff and be able to find the rules that have been hard-coded into the application.

For example, suppose that the commission paid to sales reps within an organization changed two years ago, but the rule calculating that commission was not updated. The cost could be enormous.

So why wouldn't a programmer automatically change the program logic when changing a business rule? The programmer probably would change the application in question, but could forget to address the many interdependencies with other applica tions. In other cases, the business unit might make the policy changes and not know about the under-lying applications that need to be updated.

There are three major reasons for the lack of consistency within business rules. First, IT organizations are too focused on technology and not intimately familiar with the business processes and rules. Also, not enough development tools support business-rules management. Finally, there isn't a strong link between data-modeling tools and the tools for implementing business rules.

Most IT organizations focus on technology-at times to the exclusion of business issues. IT departments tend to bring business experts in at the front end of the development process to define requirements, and at the final stage, before the application is deployed, to ensure it meets expectations. IT departments also are usually preoccupied with projects such as year 2000 conversions and packaged-software implementations. Modifying existing applications isn't a priority. But with issues su ch as deregulation and a major increase in the number of mergers and acquisitions, business rules are changing rapidly. Most IT organizations can't keep up.

Software vendors share some of the blame, too. Most development tools have little, if any, support for defining, implementing, and managing business rules separately from implementation logic. Even developers with a thorough understanding of business policies often have difficulty translating that knowledge into procedural code.

Data modeling is one of the first steps in a development project. The data model defines the structural business rules by defining the terms and facts connecting those rules. Unfortunately, there's usually no link between the application data model and the actual run-time system. Portions of the structural rules, as represented in the data model, are implemented in multiple systems and are inconsistently maintained across systems. Also, there's no easy way to track more-complex business rules.

Hidden Problems
Pro blems with inconsistent business rules often occur below the surface, where business management can't see them. Because of the serious nature of this problem, few organizations are willing to go public with their solutions. A global manufacturing company that requested anonymity recognized that inconsistent business rules were the source of both inefficiencies and lost opportunities. To correct this, the company needed to identify rules that had been hard-coded into its IT systems over the course of 20 years.

Early on, the manufacturer's IT managers realized they couldn't tackle the problem alone. Instead, they needed to work closely with businesspeople who could identify the rules that needed changing.

IT and business management realized that changing these rules would require alterations to some 140 systems-and considerable time and money. The executives knew they needed to approach upper management and request funds, but how do you explain to your boss that somehow the systems the enterprise relies o n for its very survival are out of sync with the business, and that to fix the problem will cost a huge sum? Is it really cost-effective to spend the time and effort to correct and standardize business rules? The manufacturer's project team showed that the changes would be economically advantageous.

The manufacturer sells more than 5,300 products. Throughout the product life cycle, the products are called different names in different systems. Like most companies, this one never formally determined what characteristics make each product unique or define that product. This situation developed gradually as the company evolved into a decentralized business in which each manufacturing site operated independently.

Once business pressures changed and issues such as heightened global competition forced a more efficient, integrated operation, the company needed to react-changing its data, systems, and organizations. Fundamentally, the company needed to maintain consistency in the systems and procedures that cont rol the core of the manufacturing value chain-acquiring, producing, packaging, and distributing products.

IT management considered the project's implications on the operations of the enterprise, including:

Short-term impact on business processes: Standardizing rules meant changing manufacturing resource planning (MRP), quality, and planning systems, as well as thousands of documents.
Project scope: The project affected the processes at the core of the business, including financial, purchasing, and MRP systems. Additionally, the daily work of thousands of employees at more than 150 plants and distribution sites would be affected.
Interaction with regulatory agencies: By changing how products were identified, the company would also change the information it provided to regulatory agencies.

The first step was to create a formal project team with members from the IS and business departments. The company held workshops to make sure the business experts and the IS organization worked together to define the company's business rules. Once these rules were clearly understood, the business scenarios supporting them were finalized and tested. They were then validated by a wider group of key business experts who run the operations that use these business rules globally.

The company used Oracle Designer 2000 for capturing the data model, a Microsoft Access database to capture the business rules and identify the owners of those rules, and Excel spreadsheets to capture and model the analysis data.

More sophisticated technology can also play a major role during this phase of the project. Tools such as those offered by DBStar Inc. and ReGenisys Corp. can help locate and extract rules from existing legacy systems. This will provide a better understanding of the scope of the overall standardization project.

Once all the rules are defined and understood, the overall costs and benefits of standardizing them must be determined. The manufacturer had its business experts determine the areas of greatest benefit based on their knowledge of the material and product value chain. To make the analysis available to the decision makers, the project team then clustered these costs and benefits into groups called influences, which were then visually mapped to an influence diagram (see chart, right).

Reductions in costs for packaging design and distribution-chain development because of improved data quality and decision making were clustered into a grouping with other benefits that came in the area of supply-chain design and analysis. The costs of tracking identical finished product items and lost improvements in forecasting because of nonstandard product definitions were mapped to a cluster called improved planning. Once mapped, the influences were further decomposed with high, medium, and low numbers or percentages so they could be quantified.

Assigning a dollar value to the massive effort to standardize the rules is no trivial task. One approach to consider is Economic Value Add. This approach evalu ates an investment opportunity by calculating the return on investment in terms of all the economic components of the company, including capital expenditures, human resources, and plant and equipment costs. This is usually done by calculating the cash-adjusted operating profit and subtracting the cost of the capital needed to produce the earnings. A positive Economic Value Add means that the investment contributes favorably to the enterprise's economic value, while a negative one means the opposite. The manufacturer's Economic Value Add for the project was impressive-$165 million over 15 years.

Validation Needed
But the justification for the project isn't complete once the Economic Value Add is determined. Because of the size and scope of this type of project, users would be foolish not to validate that figure and confirm that the actual business numbers are not significantly above or below the calculated Economic Value Add. One approach is to analyze each influencing factor, such as procurement, inventory reduction, and distribution efficiency, and have the business experts attach a level of variability to the numbers for the Economic Value Add.

The company in our example went a step further. After analyzing the influencing factors, the task force visually modeled these values in a tornado diagram (see diagram, p. 4A). They then modeled the impact of more than 80 different risk scenarios and performed worst-case and best-case testing. For this company, even the worst-case scenario showed a positive Economic Value Add. With this type of validation in hand, IS and business managers were able to prove to upper management that the company should proceed with the rules-standardization project.

Business rules are a fundamental building block for information management. They are the key link between business policies and procedures and the systems that support them. The challenge users must address is convincing upper management of the urgency of correcting and standardizing these business rules. The only way to do this is to provide compelling evidence in language business management can easily understand.

IS managers are responsible for managing the data necessary to carry their company into the next millennium. Whether it's a small company with a limited IS budget or a multibillion-dollar enterprise, one thing is clear: Implementing an IS project requires the ability to make quantifiable decisions. Justifying massive project expenditures based on intuition or industry direction is simply not enough. A return-on- investment analysis provides the evidence business managers require. This approach can effectively bridge the communication gap between IS and business professionals.

The analysis model outlined above provides the information required to cost-justify an architectural project. In many instances, this up-front cost justification makes the difference between successful projects and those that should never have been initiated in the first place.

Michael Barnes is an analyst at Hurwitz Group Inc. in Framingham, Mass., and can be reached at mbarnes@hurwitz.com . Ellen Gottesdiener is president of EBG Consulting Inc. in Carmel, Ind., and can be reached at 73201.3153@compuserve.com .

Back to News in Review