Monday, 5 March 2007

Case Management

Bruce Silver asks, and provides an answer to, the question What is Case Management? in his blog BPMS Watch .

To me, case management is about the organisational responsibility for dealing with a problem. IT people and increasingly, business process experts like to believe that the business problems can be modelled and coded so that the solutions are just waiting for an instance of the well known problem to arise. However, the essence of dealing with problems presented by real people is the need to adjust the process to the problem at hand within the current instance.

Whether the case is provisioning to a customer, delivering an entitlement or meeting a contract, innovation in the process is a desirable state of affairs.

For any 'case' we need to be able to answer ... Who has the ball? What is the plan? Where are we up to in the plan?

In some cases, the ownership of the case may be accepted with the understanding that the owner has to decide how best to deal with the problems presented (the health 'business' is an example of where the activities within the case may be novel and certainly the treatment plan may be a unique arrangement of activities).

Case management could be regarded as

  1. Problem Manager Accepts Case ;
  2. Problem Manager Chooses or Develops a problem resolution process;
  3. Problem Resolution Process;
  4. Problem Manager Closes The Case.

A more general view suggests that the process path to the final outcome of a case is dependent on more than one development of a new problem resolution process
  1. Problem Manager Accepts Case ;
  2. Loop until resolved
    1. Problem Manager Chooses or Develops a problem resolution process;
    2. Problem Resolution Process;
    3. Problem Manager determines whether problem is resolved;
  3. Problem Manager Closes The Case.

Case Management adds value if the the subject (customer; social welfare beneficiary; medical patient; legal complainant) and the organisation can identify where they are in the resolution process.

A BPMS supporting this aspect of case management would need to treat the process design and development as a piece of normal business. Ideally the business of the process designer is handled in the same way as any other aspect of the organisation business

  • Define a new (executable) process, message, document
  • Manage the delivery of a process into the execution arena
  • View the current state of cases through a developing business process in management dashboard and other reporting tools
  • Support cases within cases (if it turns out that a case is something distinct from a business process)

Given the preponderance of Visual Studio and similar developer workbench approaches to solution development, a fairly radical change seems to be required from the BPMS providers.

There are some real advantages to be gleaned from treating business process innovation as a normal part of business in the BPMS toolset as well as the business.

  • The ability to change is inherent in day to day processes;
  • The paralysis associated with the need to analyse everything in great depth and through vast numbers of future scenarios can be avoided.
  • Case managers do not lose sight what is actually happening because the process management and reporting systems actually deal with what would otherwise be an exception case.
  • Process designers can use the standard BPMS tools to understand the 'as is' processes because they are not hidden in ad hoc spreadsheets and MS Access databases

No comments: