Monday, November 16, 2015

Ten Truths of Business Rule Complexity




In order to automate business processes, you need to understand the underlying business rules of your organization.  Analysis of business rules is time consuming, and complex business rules add to the time and expense of software development.

Based on my experience in developing business solutions, I would like to offer the following observations to help organizations understand how business rule complexity affects them.
  1. If you think your business rule is simple, you are not thinking hard enough.  Many business rules seem simple but turn out to be complex on closer examination.  For instance, you may have a rule that a contact person may be listed only once in your Customer Relationship Management (CRM) system.  If each contact may be associated with only one account (or company) record, what can you do when a person acts in a different role for different organizations.  For instance, I can be listed as a customer of the phone company as the primary contact for my company as well as for my home phone number.  Even something that seems simple such as a company name or DUNS number can be complicated.  Some companies have one or more DBA names as well as official company names. A large company can have multiple DUNS numbers and it would not be obvious which is the correct one. 
  2. Automation involves simplification. If you built a model of the world which faithfully represented all the complexity of the world, you would have created another world as complex as the one you were modeling.  One of the purposes of a model is to simplify.  The trick is to find out which simplifications produce business benefits and which ones are not possible.
  3. Complexity alone does not determine the level of effort for automating a business rule. Some complex business rules are simple to implement and some simple business rules are hard to implement.  A complex business rule which operates on easily determined and unambiguous data can a quick programming task, while "fuzzy" logic in a business rule can be challenging to automate. 
  4. Counting the number of business rules does not directly yield a cost estimate. This is a corollary of the previous point.  Neither the number nor complexity of business rules are the sole determinants of cost.  
  5. Look out for exceptions. It's not the rules that will cause the greatest problems, it's the exceptions.  In many cases, you don't find out the exceptions until it's too late, when users are testing a new system.
  6. Words are important in defining business rules. Like law, business requirements analysis requires strict attention to linguistic details.  People at your organization may use different words to refer to the same thing, causing confusion and ambiguity in your system.  You may need to create a glossary and conduct training for users to understand the meaning of business terms terms such as account, contact prospect, customer, lead, order, purchase order, and quote. Most businesses have their own terms of art and acronyms which are important for their business rules.
  7. There is no limit to business analysis.  Unless you constrain business analysis by time or budget, you could keep going on virtually forever documenting requirements and processes without embarking on building your system.  Try to avoid analysis paralysis. 
  8. There is no pleasing everyone. Documenting business processes will highlight divergences and disagreements among people who perform their jobs in different ways.  This process may help foster greater consistency but it also may raise debates and power struggles in order to reach a consensus. 
  9. Consider an iterative approach. Automated systems and business rules affect one another, and changing one will affect the other.  You may be disappointed with the results if you try to complete your business process re-engineering in one iteration, because you may not be able to predict all the impacts of your changes in how people work.  If you allow for feedback and multiple iterations, you are like to arrive at a better solution in the long run.  
  10. Some processes should not be automated. The most common goals for automation are to improve productivity and reduce errors.  Some business processes may have so many exceptions that they are no longer fruitful to automate.  Leave room for human judgment in your automation if you are having trouble forcing the software to make all the decisions. The most successful systems use computing where it works best and trust humans in the scenarios where they can contribute most. 
In short, understanding business rules is essential to most business software development projects. Implementing new software is an excellent opportunity for business process engineering. By keeping tradeoffs around complexity in mind you can arrive at a more successful implementation and a better performing organization. 

1 comment:

Richard C. Lambert said...

In order to automate business processes, you need to understand the underlying business rules of your organization. Analysis of business rules is time consuming, and complex business rules add to the time and expense of software development.business technology