links for 2009-06-26

On Creating Successful Business Rules

Today, I attended a webinar by FICO called “11 Secrets of Creating Successful Business Rules” for which a recorded version should eventually be available (see www.fico.com/events). Here are some of the takeaways from that webinar.

[Update: 2009-06-26] The recording is available at: https://www106.livemeeting.com/cc/fairisaac/view?id=06242009

Oversimplification

Some people oversimplify Business Rules Applications and make claims that may give a sense that business rules is easy, but we should be wary of such claims.

A developer may claim that they can write a certain number of rules per day but can the business user modify them? Are these rules documented and traceable to the original source of the rule? Could the rules be audited?

Others may claim that all rule engines are the same, it’s all in a spreadsheet. What about other types of rules such as decision trees, scoring models, etc. What about reuse of the rules?

A quick regression test of the rules is sufficient. Does a quick regression test check for missing conditions, overlapping rules, contradicting rules? With that level of testing are we reasonably certain that there won’t be some unwanted side effects to rule changes?

The 11 Secrets Of Creating Succesful Business Rules

I won’t go into all the details of the secrets here, but this should give you an idea. For the details, you can go to the presentation.

11. Select the right application

I’ve covered some of the characteristics that make an application a good candidate for rules before in this post, but in short: Are rules changing frequently? is there a short time to market window? Do the rules need to be maintained by Business Users?

10. Follow a methodology

ILOG and FICO have the same idea. Use an iterative methodology, RUP inspired. Start small and build bigger and steps.

9. Document, Document, Document

Detailed and rigorous documentation is required. Use document templates to make your life easier.

8. Manage Traceability

Make sure that the traceability to law, business unit and owner is documented as well.

7. Analyze & Establish Rule Quality

There are qualities of good business rules, conciseness and atomicity are the two qualities that were touched in this presentation. Hmmm… That gives me an idea for a new blog post…

6. Choose the right metaphor

Basically, use the right representation of the rules to fit the needs of the business. Drop down boxes? Decision tables or trees? Scorecards?

5. Validate the Rules

Have the business users configure and run test cases.

4. Perform Complete Verification

Verify the rule logic with tools, not manually

3. Simulate to Analyze Business Impact

This is to make sure that although the rules might be correct (see Secret 5.), that the effect of the changes has been measure to the fullest. What is the impact to the numbers in the end?

2. Structure for Reuse and Governance

Make sure that your business rules repository and processes allow for proper governance and management of the rules.

1. Operationalize Analytics & Improve Decisions

This is the item I am most unclear about. It seems to be taking simulations (Secret 3.) to the next level. Creating some mathematical models to estimate some pre-determined KPIs.

If you find this post somewhat interesting, I suggest you go see the recorded webinar.

[Update: 2009-06-25]

As I was browsing looking for something else completely, I stumble on the associated white paper from FICO which can be found here: http://technology.searchcio-midmarket.com/document;5136646/midmarket-abstract.htm

links for 2009-06-19

links for 2009-06-18

On taking BPM to the Enterprise level

Today, Sandy Kemsley was giving a webinar on how to take a BPM project from a department to an Enterprise Program.

The presentation will be available soon on the BPMbasics web site at http://www.bpmbasics.com (look for BPM 106).

Projects often have intents of eventually going to a program and enterprise level, but many times, the intent just dies and nothing happens. Some of the reasons for this is that solutions are sometimes overly customized, there is no strategic vision and there is a lack of skills.

On the other hand, there are some great benefits to be expected from enterprise level BPM. Processes can be cross-departmental, it removes ad hoc parts of the processes but it also mainly provides the opportunity for an enterprise level dashboard of all processes. This last point is usually a great selling point with management.

To take the BPM from Project to Program (some highlights):

  • From initial BPM Project develop a CoE
  • Promote the project success internally
  • Develop a strategic vision
  • Consider SaaS BPM for faster deployment

Among the common pitfalls, Sandy mentions that one mistake is to try and analyze all the processes before trying to get a solution. She suggests that finding the most important categories of processes might be a better idea so that it does not get stuck in some analysis paralysis.

Another pitfall she mentions is the use of the wrong BPMS tools. She proposes that it is better in the long run to actually bite the bullet and change BPMS tools if the wrong one was used initially although there may be some costs in time and money to do so.

If implementing enterprise level BPM, you should expect some changes on the technology side (hardware, software, security, etc.) and on the business side (new processes, etc.)

One of her key takeaways is to start small but think big. (Or as Stephen Covey would say: Begin with the End in Mind). Having a vision of the destination (enterprise level BPM, Coe, etc.) is essential. The Center of Excellence should also come as early as possible.

A quote from her final thoughts:

“BPM programs don’t just happen, they have to be built”

Questions on the CoE

After the main presentation, the Q&A period had a lot of questions regarding the CoE.

When asked how to staff the Center of Excellence, Sandy responded that in most cases the people involved in a BPM project have been pulled from their operational duties. the trick is to keep some of those key people to start building the CoE and possibly have some new hires to complete the team.

She also mentioned that in a CoE most of the staff will be there only temporarily. Stays as short as 6 months, but more commonly 1 year stays are to be expected. Some of the more technical experts can be in the CoE for longer.

Concerning the size of the CoE. A CoE will typically have a core team of 4-6 people, but can be much larger depending on the size of the enterprise.

Overall an excellent presentation. Look for the recorded version on the bpmbasics.com web site.

links for 2009-06-17

Presenting at the Business Rules Forum 2009

I have been confirmed as a speaker for the Business Rules Forum 2009 in Las Vegas, NV in November 2009 (http://www.businessrulesforum.com).

The title of the talk is: Business Rules Governance and Management: A Case Study in the Public Sector

If you read this blog and are coming to Business Rules Forum 2009, feel free to come talk to me!

Presenting at BRF 2009