BPM: It’s About Managing Change (Fourth in a Series) - Rules, Rules, Everywhere Rules....

So, from even the list of examples in my previous post, it would appear that rules are everywhere in a business, and this is in fact a testament to the value of managing business rules effectively. For the most part, though, they can be categorized in relation to how they impact the other two main components of information systems: data and process.

For your data needs, business rules help with conditional relationships and data values. Consider the example of when an order qualifies for a discount. When an information system is used to create a new order, the database schema would have informed the programmer that certain data attributes are needed to create a complete and correct order — like item and discount — and what values those data attributes are allowed to be for the order to be considered valid for the business. However, a database schema cannot document and enforce rules about values of a field that are dependent on the values of other fields; those are rules. Further, if an order needs to have an association with a credit authorization when payment is by credit card, that is a conditional data relationship that cannot be described in a database schema; it is a rule.

For your process needs, business rules are critical for the decisions made in a process. Basic implementations of a BPMS will automate the flow of activities but will stop executing and exit to a user prompt when it reaches a decision point, the diamond in the diagram. A person needs to respond to the prompt and indicate which path the process should follow next. This is better than not having a BPMS, but it is not yet an ideal implementation.

Why? Consider that most decisions made in a business are consistent and ongoing applications of rules (e.g., does the customer qualify for a discount on this order?) and are made many, many times a day. In these situations, the person is looking up the rules in a manual or, worse, applying them from memory, which we all know can be faulty in even the best people. This is where BRM has its biggest impact. It can elicit those common rules out of the manuals and memories and get them into a BRMS, and then business processes will flow uninterrupted until a new situation arises. That is when a person is really needed, and once the new situation is understood, it too can be defined as a rule and added to the BRMS.

Next Time: A Model for Business Operations - Process , Data and Rules

BPM: It’s About Managing Change (Third in a Series) -Supporting Business Rules; will Brute Force work?

"....systems that implemented the data edits in program code were subject to even more requests for change, along with the requests to change processes; thus the backlog started to grow seemingly exponentially."
 
Many organizations tried to solve this problem with brute force: adding more resources, running more projects, outsourcing what could not be done internally. Other (fewer) organizations saw the diminishing returns that approach produced and started evaluating the problem laterally. They determined that data definition and then process definition captured a lot of what business is about, and automating their management was of benefit, but neither included "the set of rules that determine how a business operates — that is, rules that prevent, cause, or suggest things to happen." ("Defining Business Rules — What Are They Really? Final Report, Revision 1.3." Business Rules Group, July 2000)

These organizations realized that just as data needed a DBMS, and process needed a BPMS, business rules need business rules management (BRM) and a system to support it: a BRMS. I’m not talking about codelike procedures; these are human-readable rules that can also be implemented as declarative statements, such as:

- A customer can place an order, only if they are 18 years or older.
-A customer can place an order on credit, only if their credit rating is "good" or "excellent."
-The insurance coverage for a 10-year term life insurance policy must be $50,000 or higher.
- Premiums paid by direct debit must have a monthly payment frequency.
- A credit application greater than $1,000,000 must be approved by the manager of underwriting.
-An order is fulfilled, only if the ordered items are in stock.

As declarative statements, business rules need to be automated irrespective of any procedural order. All rules are applicable to the business at any time, not according to any order specified in a coded program. The structure of the rule statements must meet the two primary needs: readability and execution. The means of accomplishing this, fortunately, have already been developed and standardized for us through the OMG and its "Semantics of Business Vocabulary and BusinessRules (SBVR), Version 1.0.". The above examples meet the requirements of this standard and would be executable by any BRMS that supports it; so now your rules are don't have to be frozen in code.

Next time: Rules, Rules, Everywhere Rules....

BPM: It’s About Managing Change (Second in a Series) - Things change, but are they really different?

We can agree that business processes change a lot, but a little analysis of the nature of these changes reveals that they are of the same type(s): activities are added or removed, or the order of the activities is rearranged, or the criteria used to make decisions changes. This is what business process management systems (BPMSs) were created for: defining activities, decisions, and their order in a business process, with the ability to change the process in common ways without requiring an IT project. The power of a BPMS stems from identifying these stable patterns of change and supporting them with structures — activities, decisions, and the definition of their order — that allow for change.

THE DATABASE ANALOGY

To illustrate the point of stable change, consider database management systems (DBMSs) as an analogy. A database embodies a model/structure of an organization’s ongoing data needs, patterns of entities/objects, and their relationships — what database analysts know as the "schema." With this stable structure, new occurrences of data are added as needed through application systems; the need to add new data item definitions to a database is very infrequent, occurring only if the business of the organization changes significantly or the organization enters a new business.

Further, databases are not just containers; they are rule enforcers.The optionality and cardinality defined for relationships are rules, such as "an order must have at least one item being ordered but can have many items being ordered as well." This is what any business person will tell you is true about an order, so a database can be used to enforce these rules.

This enforcement is good, but it is also limited. Database rules, especially optionality, are cut and dried; they cannot implement conditional situations, such as "a relationship is mandatory only when x=y." For example, an order must be related to a credit approval if the payment method is credit card. When the business presented this kind of situation to IT, the data edit was born. As you might expect by this point, this response was implemented in code and used primarily when a new occurrence of something, such as an order, is created by an application system. It has also been known as the input edit, the screen edit, and the field edit. A special case is the cross-edit, where the value of one data attribute is constrained by the values of another. For example, a discount for an order can be greater than 25% only if a certain type of item is ordered.

This solution using code has caused even more problems than the examples described previously, because "data edits" are a technical IT term for business rules, and what I have learned is that business rules change even more often than the business processes that use them for guidance. Working in insurance, and then lending, I have often seen code that implemented underwriting business rules to automate decision making, only to then see the business rules change enough that the results produced by the code were no longer valid and had to be extended by manual workarounds. So the systems that implemented the data edits in program code were subject to even more requests for change, along with the requests to change processes; thus the backlog started to grow seemingly exponentially.

Next Time: Supporting Business Rules; will Brute Force work?

BPM: It's About Managing Change (First in a Series) - Why are Business Processes frozen?

Despite many things written and said about businessprocess management (BPM), it is really one thing for certain: an automation improvement that supports change management.

WHY ARE BUSINESS PROCESSES FROZEN?

Business processes are the lifeblood of an enterprise, moving and shifting to respond to the ever-changing business environment. They are sets of activities in an organization that are performed in response to a trigger— an external stimulus, an internal state change, a point in time that has been reached — to provide a desired result in response to that trigger.

The nature of business processes lends itself to diagramming them in some manner. You can present the starting and end points as circles, all the activities as boxes, decision points as diamond shapes, with arrowed lines connecting all of the above (swim lanes optional). What all this drawing means is that, given sufficient effort, it is possible to fully define a process as it exists at a point in time.

Why the emphasis on a point in time? Consider how most businesses’ processes and activities were automated for the first time: the process was defined, and programmers designed and coded programs for a system that executes the activities. On the day the system is implemented, and for some period of time afterward, it does what it was designed to do, and the business performs its processes using that system. No one is aware that the business process is now frozen in time.

Fairly soon, however, the business decides to change its process somewhat to deal with new problems or opportunities. The system does not support this changed process, so a project is needed to open the system, make the changes (correctly), test the changes, and implement the new programs for the system. This takes time. The business process essentially must be thawed out, redirected, and then refrozen.

By the time this effort is completed, however, the business has more changes lined up. Here we see the arrival of the two curses of information systems: (1) the backlog, and (2) the workaround.

Next time: Things change, but are they really different?