Context sensitive Rule Management – Part 2

In my March 28th blog, I discussed process centric thinking and mapping business rules to process. As I stated earlier, business is a set of processes/services that it provides to its consumers. Business rules define how each process functions and how processes taken together allow a business to function. Let’s take an example of e-Commerce web site which takes orders from customers and fulfills customer’s orders. In this case, one process for this organization is, “Order fulfillment”. At the highest level it can be defined as
Gather customer information
Gather items that customer ordered
Take method of payment
Place a block or authorization on payment
Check the stock to fulfill the items that customer ordered
Place them in one or more boxes
Ship them to customer
Upon customer receipt, charge him.

Each step may itself explode into complex multiple sub steps or processes. So depending on organization size and number of processes; interactions between them may be very complex to define. When enterprise wide initiatives are made, even at the process level, people quickly get confused in communications primarily because they lack a common enterprise-wide vocabulary. The solution is to get control over what business can be defining by:

1) Creating common enterprise wide vocabulary thru which every one can communicate. (No interpreted meanings. Clear definitions)
2) Creating processes by using the vocabulary defined above to the granularity desired
3) Creating teams to define a process or sub process with an understanding of its functionality in end to end process definition.
4) Defining Requirements using common vocabulary (Enterprise repository) and creating any additional vocabulary before using it in Requirements

Strictly following the above rules automatically applies the concepts of “Contract first”, “SOA”, “Integration from day 1”, and handful unambiguous documents.