Author: Sandra Sears

Business Rules – A Case Study

Written by Sandra Sears on January 30, 2018. Posted in Articles. 1 Comment on Business Rules – A Case Study

What exactly is a business rule?

According to the International Institute of Business Analysis, “a business rule is a specific, practicable, testable directive that is under the control of the business and that serves as a criterion for guiding behavior, shaping judgments, or making decisions.”

Business rules have impact beyond the scope of any particular project and are applied across the organization. A specific rule may impact operational processes (as in a rule that describes the time period during which a request must be fulfilled), enterprise data (as in a rule that describes a calculation), roles (as in the requirement to establish a new audit function), and events (as in a rule that requires reporting to a government agency for transactions in excess of a certain dollar amount).

While business rules are defined as being under the control of the business, the need for a business rule is often triggered by an external entity, through laws and regulations, through the actions of competitors, and through the behavior of customers. In this regard, the urgency to implement a business rule may not be under the control of the business.

Mitigate risk by being proactive

We believe that the “business rule” risk (along with many other risks) is mitigated by infusing business analysis competency into the organization – a business analyst can help bring order to sometimes chaotic processes and can serve to help mitigate risk in enabling an organization to quickly assess and understand the impact of a proposed change.

One company’s story

One of our clients, a mid-size insurance company, realized the need to move from a plethora of policy administration systems to a single integrated system that would enable the company to move products to market in a more integrated and rapid fashion. Prior to even considering candidate solutions, the company embarked on an architecture modeling endeavor, using process analysis techniques to understand their current state, identify process gaps, and appreciate opportunities for process improvements. As part of this process, they captured and documented business rules inherent not only in their existing systems, but in processes and procedures across the organization.

This company found that the work that they had already completed began to pay immediate dividends, and was clearly enabling the company to mitigate a non-trivial portion of the risk associated with such a system migration.

Prior to and then in parallel with their vendor search, the company began to collect and document their business rules. Like most other companies, they found that business rules were hidden in policy documentation, subject matter experts’ heads, and in system code. The work to collect the business rules was painstaking, but the long-term benefits of this effort soon became apparent.
The company quickly eliminated several candidate vendors, as it was clear that the solutions would not meet with company’s needs or could not support each of the product types that the company offered. By mapping key business rules against these vendor solutions, it was evident to both the vendors and the company which solutions were not appropriate.
The response from the vendors whose products were candidate solutions was one of delight! Most vendor solutions today are highly configurable, and the ability to configure is based on a solid understanding of business process and associated business rules, so these vendors knew that their implementation pathway had been well paved with this analysis work.
Having developed a business rule capture and maintenance approach along with diagrammatic models that depict processes, data, events, and roles, the company will be able to quickly ascertain in the future what the impact of the development of a new product or the implementation of a rule change will mean, as the rules will be traceable to the products, processes, data, events, and roles that each impacts.

What were the benefits of using modeling and process analysis techniques over how the company had previously attacked product development?

Thinking about their business in a systematic way – its rules, its events, its roles, its calculations – made the process more focused. The team used business analysis facilitators both to elicit the required information and then to document it. The business analysts were also responsible for building the diagram representing the business architecture. Everyone agreed that having the diagram made the business processes and rules visible and, therefore, easier to discuss and change. It also provided a means for communication and collaboration among the team members.
Each product – its architecture and the rules it would use – was documented in a repository. If additional riders, benefits or components need to be added in the future, there would now be a single source for that information.
Performing business process analysis on all of the in-scope operational processes built a base of process flow maps and associated rules. These could be saved in a repository and, for any new development effort (including the anticipated development of new and innovative products), could be analyzed to identify areas of change.

It would be impossible to overemphasize the value of having the organization’s analysis assets in a repository. The requirements, workflows, rules, and overall process models were documented in an on-going, living data and requirements repository, available for use for the next development effort. In a way, these requirements will become the reusable code of the business and product development process and, as such, the product and rules architecture models. The process models and the requirements are tangible company assets, ready to jump-start future process improvement undertakings. Such models lay the foundation for a library and formed a solid basis for continuous optimization through a solid understanding of rules, requirements, and business process models.

All agreed that without the full-time commitment of strong, professional business analysts, none of these benefits would have been realized. As a result, the organization is in the process of building its own internal business analysis and rules expertise. Their desire is to continue to reap the benefits of mitigating risk through a disciplined business rules and analysis approach.

Business Rules and the Importance of the Business Analysis Discipline

Written by Sandra Sears on October 11, 2017. Posted in Articles.

For most organizations introducing a new product or application system or responding to a policy or regulatory change can be a daunting process.

Add to this the fact that rule changes or additions are often externally imposed (by government or regulators), and organizations face significant risks associated with complying with such new or changed rules in an efficient, effective, and timely manner. Similarly, most system replacements or “legacy system modernization” efforts fail, usually after the expenditure of hundreds of thousands or millions of dollars.

If an organization understands, captures, and documents its business rules, the understanding of the impact of any change is much simpler; impact analysis is clear; and, the road to implementation of a change can be planned and managed successfully.

How do we identify business rules and where do we find them?

Business rules guide behavior, shape judgments, and drive decision-making. Thus, we can extract business rules from company policy statements, procedure documents, product descriptions, filings, and operational documentation.

Certain business rules may be maintained only through “tribal knowledge” and thus exist only in the heads of employees. There will be knowledge loss associated with staff attrition if an organization has not taken the time to explicitly document business rules.

Many business rules are hidden in application code. This may be due to the complexity of many insurance application systems and to the fact that those systems may be undocumented or poorly documented (or the validity of any documentation may be in question). Staff members may not even be explicitly aware that these business rules exist.

Because of the siloed nature of many organizations, conflicting business rules may exist in different areas of the company, again increasing risk to the insurer of undesirable outcomes.

The products of business analysis and the use of a business rules approach can provide clear direction for the discovery of business rules and the ability to trace business rules to the processes, events, roles, and data that they impact. Business process models have “decision” points (indicated by a diamond). For all but the most rudimentary of decisions, these indicate the application of a business rule. The creation of a use case description generates questions that are answered by the discovery of business rules. The analysis of data entities and their attributes trigger the discovery of business rules through the exploration of “how does A relate to B?” Assessment of a business role (possibly through the creation of “personas” – Sally is a twenty-something, tech-savvy individual who hates to have to “look things up”) can also trigger discovery of business rules.

A business rule example

Let’s use a completely hypothetical example of an external event triggering a change to a business rule for a disability insurer.

Most disability insurance policies will provide monthly income in the case of a disability only until age 65. This rule provides the insurer with (1) a clear limit as to how long disability payments must be made, (2) protection against disabilities that occur after age 65 (when disability is much more likely to occur), and (3) the ability to price policies based on actuarial information for a population of age 65 and below, whose risk of becoming disabled is far less than for a population in excess of age 65.

However, today most Americans are working beyond age 65, and Social Security’s full-benefit retirement age is slowly increasing. As a hypothetical, let’s assume that the government passes a law that disability insurance must cover insureds until the age of 70. What is the potential impact of this change?

How disruptive (and therefore risky) can the assessment of a change in a business rule be?

This “minor” change in disability rules would have a sweeping impact on a disability insurer. What are all of the processes, procedures, calculations, documents (such as contracts), and roles that are impacted by a potential change to the rule concerning when disability payments will cease? How many insurers are likely to have immediately available information to answer this question?

The likelihood is that few insurers could respond to this question without undertaking a great deal of research. A change to the simple rule expressed above will impact virtually every area of a disability insurance organization. Constraints imposed by both internal and external stakeholders, such as time constraints for implementation and the need to conduct actuarial analyses based on the change in underlying product assumptions, complicate the situation even further.

The need to adapt quickly to change

To ensure an organization can respond to market, regulatory, and desired product and application changes, the ability to adapt quickly and accurately must become a core competency. This means that the lifecycle for change must be measured in days or months, not years. For many organizations, this seems a truly unattainable goal, leading to the necessity of continuing to deal with the costs of rework and lost opportunity. In the disability insurance example above, it could even lead a company to withdraw from the sale of an entire product line.

The inability to respond rapidly, efficiently, effectively, and accurately to change (particularly change with a fixed deadline imposed upon an organization by an external entity) is a risk of which most organizations are aware, but are uncertain how to address.

The key to rapid adaptation lies in truly understanding one’s business. While the initial investment in business analysis and the documentation of process and rules may seem significant, the long-term payoff to the business is an ongoing return on investment every time a business faces a change – be it a regulation, a new product, the need to modernize technology, or even a changing customer environment. Technology alone cannot solve the problem of change, but the products of business analysis do provide the key to success.