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
No comments:
Post a Comment