Regards.

Jon Pyke’s Knowledge Intensive BPM, or KIBPM, which according to a white paper on , is defined as a mix between:
a) Case Management
b) , term and theory developed by Keith Harrison-Broninski. I have the feeling HIM will be getting a lot of attention in the near future, especially if Peter FIngar calls it .

Rafael.

Case management is typically about managing a number of different (possibly related) case types. Unless you can distill any new piece of work down to something that is manageable (and broadly repeatable) – it is very difficult for staff to know where to start each time, and that’s part of the objective of case management, to avoid re-inventing the wheel. To my mind, the essence of case management is to establish the most applicable or usable “standard” handling for each specific case type, catering for the majority of scenarios, ie not everything has to be modelled. When you have a case instance that doesn’t fit the existing standard you can react in one of two ways (a) give it to your most competent staff who, based on experience, knowledge etc will know (or discover) how to deal with it (b) extend the existing case definition so as to bring more case scenarios within the core case definition itself. I find that (a) often leads on to (b), but this is just a natural evolution of any process-based scenario….

Cases could be over-defined – where every possible scenario is identified, modelled, and implemented. Anything that is too prescriptive is likely to fail for this very reason, this is why flexibility is essential, again a characteristic of case management. Equally flexibility should NOT mean no-process, no standardisation etc – otherwise there is no safety net. Perhaps flexibility should equate to getting the granularity of the modelling correct, particularly as it applies to human actions – neither too high-level nor too low.

To pick up on other points, using the TelCo example from rafable, I would regard each of the items such as site survey, local loop check, connectivity test etc as being individual case processes, which can exist within an overall case – e.g. “TelCo Onboarding”? The case processes are “marshalled” as appropriate within the context of a single case in order to achieve the case outcome. Some case instances might need all of them, others may not. Hopefully I haven’t over-simplified in this scenario – this is just to give the general idea of the approach.

Work distribution for individual tasks (process steps) can be achieved by defining one or more “roles” at the individual process and/or case level, together with static organisational groups or teams. Roles can be (re)-assigned dynamically within each case instance so as to distribute work to the necessary resources anywhere in the organisation. This is a great way of engaging staff across a large enterprise to achieve a shared business outcome, particularly if everyone interacts through the same “case” framework. The “case manager” or “case owner” is often the person who has oversight (and responsibility) for the overall case processing. So the “case manager” is just one specific role in the overall context of a case, whereas there are typically multiple roles involved in the successful execution of most cases. Getting the roles and task sequencing (dependencies) correct goes a long way to addressing case management needs, optimising throughput and time to completion, particularly with parallel processing scenarios. Traditional case processing where a case is just “handed” or assigned from one person to the next implies linear processing, which is much less effective overall.

In Singularity terms, as part of the overall support for case management, multiple roles can be defined at case and/or individual process levels – there is no particular significance in one role versus another. At execution time, each user wants to see the list of tasks that they are charged with – typically spanning multiple case instances (the in-tray model). When working on a specific case, the user will want to see the case-specific task(s) that he or she is tasked with – but equally the tasks assigned to other case role occupants (folder model), and ideally a graphical view of the overall case processing to understand the current state of the case. I find the latter feature is very popular with users – ie to be able to have a visual overview of the case processing. So for case processing – various models of rendering the current workload are required – by person (in-tray), by case (folder) and graphically.

To summarise my views on Case Management, I see it as a specific “application pattern”, which aligns a range of technologies in an integrated but flexible manner, but which has broad applicability to a number of problem domains. I see the occurrence of this increasing in a multi-channel (email, e-form, voice, paper etc), services dominated market – e.g. in relation to financial products – KYC, on-boarding, compliance, complaint handling, investigations, service delivery amalgamation within organisations etc. Case management is a formidable approach to managing interactions successfully, particularly with one or more external parties in typically complex real-world scenarios. This then creates opportunities to add value, streamline, reduce cost and increase consistency of case process application.

The fact that “case management” lacks a robust description at this time may be an issue that curtails its uptake – this is why I am so glad to see the active discussion and debate around this topic. May be we just need to find a new title or acronym for Case Management such as BPM++ perhaps, since Case Management relies on many of the capabilities of BPM, but more besides!

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

I look forward to the definitive word from Bruce ….

David

In government, where repeatability and strict policy adherence is required, process is typically well defined up front, while allowing case managers the flexibility to ‘case manage’ within that structure. For this reason, many case management applications seem to resemble high level state or status tracking applications than BPM tools. For them, the beauty is in a UI structure that is familiar and usable by the end-user.

In commercial environments I’ve seen case management applications fit into any repeatable business process that requires some human intervention and real knowledge based decision making. A large amount of process state is based on the requirement and receipt of external documents and information, and the effective matching of this to current cases. Much of a granular BPM(N) process model could be overwhelmed with ‘rendezvous’, exeptions and representing collaboration as parallel processes, hence case management tools carry their own individual methodologies to abstract the common requirements to something repeatable and configurable.

To handle ad-hoc and collaborative process definition within structured process definitions, an easy to use approach is to present users with ‘task management’ (dislaimer: the Global 360 Case Manager application I product manage takes this approach). This is effectively a mini project plan that guides users down paths based on their decisions, tracking the tasks as they and their colleagues perform them (perhaps a little of Rafael’s project manager approach). It allows task templates to be used based on user or application control, or users to create new tasks to meet their needs on an ad-hoc basis. This way you get tracking of processes, control over tasks performed if necessary, and complete ad-hoc operation if required.

I think that dependent on industry, we’ll all have a different definition of ‘case management’. It is less of a technology definition than BPM, instead being something that seems to be borne out of real business requirements by users that focus less on technology and more on the business goals.

Nice discussion!

Phil

The Case Manager (person) would have the posibility to monitor all assigned activities. The best way I could picture the approach was looking at the Case Manager as a Project Manager. Imagine him looking at an MS Project Schedule, but with escalation information and automatic status update for all the tasks, as well as the case documents and data at hand. He could add/cancel tasks (notification to assigned group/person included) as soon as new case information is available.

To me a “process” in this sense is just a series of tasks with precedence information, thus allowing for on-the-fly definition of processes. I know many things are to be considered in this schema, including business limitations to a process this flexible, but it’s the best solution we could come up with given the wide range of solutions we intend to offer.

I thinks psoneill’s approach would cover most of our requirements, except for the Case Manager role, which I’m not sure if Singularity considers, or if they still use a typical “tray” view for tasks and processes.

Regards,

Rafael.

What you’ve got is a case that needs to be in a certain state before it can progress. To get it to that state, you execute a number of processes in an ad-hoc fashion that may or may not result in a state change.

Each case may use a different set of these processes, or use them in a different order as the case moves forward based on the real-world events that occur.

I’d add an additional reason that real-time modification of these processes is somewhat rare–in my experience, many industries in which case management occurs are highly regulated and there’s strong reistance as a result to allowing for free-form changes to processes.

The scenario you outline – in terms of dynamically changing the processes at run-time is uncommon, mainly for business reasons rather than technical reasons – i.e. managers are understandably concerned about allowing users to make ad hoc changes to established business processes, particularly without prior testing etc.

That said, the Singularity Process Platform does actually allow you to do what you outline, and there are two possible ways to do this. A currently executing process can be “grabbed” in the modelling environment, and revised as required (not just once, but on an ongoing basis – ie multiple revisions) – this affects the currently executing process instance only. If you want to adopt this revised process definition as your new process pattern, you can then make this the new process template definition to be used as standard.

If you don’t want to give access to the modelling environment to standard users – it is also feasible to use the available APIs, say through a custom application, to add tasks dynamically – so in effect there are a couple of approaches to achieve this objective.

So in summary, adding new case process definitions to live running cases is very easily done, and there are also options in relation to dynamically changing currently executing processes – either through the modeller or through custom APIs.