Rules Rule in Case Management

On his blog , Dan Ciruli from the xCP team at EMC asked a few interesting questions about the role of a business analyst in case management system development. He has the formidable challenge putting the next generation of tools together for the suite and it is an important question to ask. He suggests that with case management, ad hoc is more often than not a standard operating procedure. This implies that traditional approaches to process improvement (and the tooling we have today) may not be the best choice.

My experience with case management bears the out. Companies and agencies alike struggle to define pathways that can be optimized to extract ROI.  Often there are far too many choices and potential next steps to effectively automate. The case may have a linear flow between high level states but within a given state there is seldom a direct pathway to the next state that is common enough to control programatically. Consequently many systems become over engineered,overly rigid and rarely if ever portable.

Dan’s question is a fair one but I’ll ask it a different way. It is not so much about what the analyst wants to do. It is about what needs to be known.  When trying to work with a customer on a case management project what information should the tools be capturing that is beneficial to automating as much as possible.  Gathering processes is important but a higher degree of attention should be given to helping analysts focus on rules.

There are always rules. If the patient has this insurance, create that set of forms. If this court case involves a juvenile apply that security. Even when the process is governed by a single person, working alone with no approval there are rules. Too often developers embed these rules in code, data validation or elsewhere and it is seldom flexible enough to permit change without significant redevelopment.

Rules engines have been a part of many BPM offerings and integrated into document management workflow projects for some time. As the market definition of collaborative case management matures the absolute necessity for rules management integrated with process definition and code becomes evident.

This means first that rule creation, definition, implementation AND maintenance needs to be part and parcel of the platform. Rule creation and maintenance cannot only be a developer activity.  The analysts are in the best position to understand the role the rules play in binding together the people, processes, and data.

Secondly the designers and implementers of these solution need to adjust their architectures and development patterns to leverage the flexibility that a well designed rules engine provides. The holy grail for integrators is repeatability and rules engines are an essential enabler of solution portability.

There are several rules engines in the marketplace both open source and proprietary. In recent months I have been spending time with Corticon and it integrates well with xCP. I especially appreciate the “excelish” rules definition process  that an analyst would be able to quickly understand and manage. The rules deploy as web services.

So my 5 cents (adjusted for inflation, taxes and handling fees) is analysts need integrated rules management in a non-technical (or at least non-threatening) tool set for application composition. BPM is important but for case management rules rule. Thanks for asking.