Top 10 Excuses to Avoid Business Rules: #3 Takes too long.

3. It will take too long to get results

3. It will take too long to get results

This excuse gets trotted out for one of two reasons – either the organization feels it is just too busy to take on something new or someone has heard that the technology requires a large up-front investment in time. Let’s take these one at a time. Most IT departments are behind – they have a huge application backlog, lists of requested changes and too many high priority projects to count. In these circumstances it can be hard to justify investing time and energy (and money) in a new technology. Why should decision automation technology be any different?

Well, decision automation can refocus energy from maintenance work to new development. Investing now can free up resources in all the subsequent quarters so you can actually start getting ahead, rather than further behind. Experience is that the first use of business rules management in a project can easily be timeline neutral or better – the time spent learning the technology is recovered in the first project. This means you can build the system in the same time or better and reduce the ongoing maintenance by perhaps 80%. If you are so busy you cannot build anything new then the high maintenance systems might be candidates for using business rules to renovate them. Instead of changing the high-change code each time, replace that code with business rules and make it easy to make ongoing change. Doing this can quickly pay for itself in dollars and time.

As for the large up-front investment argument, this arises often from mistaking business rules as an approach to analyze a business for business rules as an approach to developing decision-making services. Make no mistake, there is potential for high-level business rules analysis to help you understand your business but this is not the same as decision automation. Decision automation requires a degree of business rules analysis in the same way that good database design requires some data modeling. It does not require a complete top-to-bottom model of business rules, any more than a complete enterprise data model is required for good database design.

If you are focusing on decision automation as your goal, try and keep your modeling and source rule analysis focused on the problem at hand. Some analysis of the rules around the edge of the project and of the rules that won’t ultimately be automated is useful but “begin with the end in mind”. If you have been reading a lot about the business rules approach you can apply this to your decision automation projects but using the approach to model your business is a separate exercise. Clearly if you can justify broad business rules modeling then these models will be very useful when automating decisions but such broad-based modeling is not necessary for most decision automation projects. As an example, one of my customers went from 100% manual review of auto policies to 1% manual review in less than a year. The project only took 9 months from start to go-live (handling about 75% of transactions initially I think) in an organization with no previous rules experience and no existing business rules models of any kind. To make this work they:

• Stayed focused on their decision
• Used the BRMS they picked as their vendor recommended
• Modeled the decisions, rules and process they were implementing enough to establish a context
• Did not model the rules that were staying in the manual guidelines as carefully as the ones going into the software
• Expected to do multiple releases to drive the automation percentage up to their target rather than trying to do it in one lump.

You can do this too.