I recently received an email from Danny Greefhorst of the Netherlands, who says in relation to my 2006 BPMS Report series: “your definition of case management seems to be very document-centric and to be quite different from interpretations I have seen in other places.” He attaches a couple articles, also of Dutch origin. The note was timely, as I’m in the process of putting together my 2007 report, and item #1 on the list is revising my list of process use cases and their scoring criteria.
Here is how case management is described in the overview volume of my 2006 report:
Case management is another special type of process that only some BPMS support well. Its key artifact is an electronic folder of case documents, which are added while the case process is running. The classic example is mortgage origination, but examples include other types of underwriting for insurance and loans, financial advisory processes, and many types of benefits adjudication. What makes case management different is that the number and identities of documents may not be known at design time, and each document may have its own workflow (create, review, approve) in addition to the overall case process. Many case management processes involve complex business rules and require integration of a business rule engine.
Look for:
– Electronic case folder of independent work objects
– Ability to add case objects and flows at runtime
– Content management integration
I agree that is a bit narrowly drawn, and also hard to distinguish from other process types, notably content-centric and collaborative. So what exactly is the essence of case management, or case handling, as it is sometimes called? One paper from Wil van der Aalst, a BPM academic from Eindhoven University of Technology, describes case management as something not handled particularly well by traditional workflow or BPM systems.
- In case management, a process task (“atomic” from BPM perspective, performed by single individual, a single “state” from the process perspective) may contain various subtasks (van der Aalst calls them “activities”, but that term has a different meaning in BPMN) — all done by the task performer, but not necessarily in a prescribed order, and depending on the context, perhaps not all need to be done. The BPM process engine controls the flow of tasks, but not the internal subtasks.
- Also, in case management, the task performer should be empowered to do what is necessary to handle the case, which may be more than is allowed by traditional process design. Traditional BPM gives each task just enough information to perform the functions envisioned by the process designer. To make a long story short, case management should allow task performers to add data objects to the instance at runtime, even if such data elements were not specified in the process model.
In reconciling this view to my 2006 report, clearly the biggest difference is my use of the term “documents” vs van der Aalst’s more general term “data objects” — which obviously could represent document attachments. He doesn’t mention the idea of an electronic case folder, but obviously some general container for case data — both that defined by the process model and that added ad-hoc by task performers — is implicit. My use case needs to clarify that the entire case folder is routed by the process engine to task performers, and links the participant to all case data and documents, not just that required to perform the assigned task. The content-centric features will be removed from this use case and moved to the content-centric use case. The report will remind users that the use cases are not mutually exclusive, and a process that fits into more than one may need a solution that encompasses the features required by both.
Hi Bruce,
I’ll try to keep a long story short.
I work as an IT Project Manager at a Telecom company in Mexico. Last year I had the opportunity of coming across your 2006 BPMS Report. At the time we were using Captaris Workflow, sold to us as a “BPM” solution. After having several problems with it, we decided to create our own, very simple BPM System (we used Visio to create the process map and a Rummler-Brache like notation with basic objects which we seamlessly imported into the process execution server). It’s not BPMS 2.0, but it’s very effective! And it cost us about 80 man-hours thank God!
Now, I have to give you the proper credit, since I based some of the features on your 2006 BPMS paper among other articles found around the Net. 🙂
It took us a couple of weeks to have it up and running and currently are using it to automate key processes at the company.
A new challenge came at the end of last year when we decided to automate provisioning of Converged Services.
It turns out each Service had several tasks that had to be completed (some are optional) and delegated to different resources across the organization as well as monitored, and Services could be grouped into Products, with tasks also assigned to the product. These tasks have to be managed by a Project (Case) manager. Effectiveness and other Performance indicators could then be linked to a certain PM and his projects.
Also, there were certain fixed tasks (auto/manual/integration) executed for every Product, depending on Business Rules.
I could not think of a way to map that kind of process, but doing some research Case Management seemed to fit the bill, at least in part.
Yesterday while on an Analysis session I came to the conclusion we had to divide the Process from the Project (Case). Process being the fixed tasks needed to provision the service and Case being the rest of tasks that needed closely monitoring and delegation, as well as on-the-fly generation.
Thank you (once again) for your timely industry insight, and the useful link to the Case Handling paper.
Regards,
Rafael
Hi Bruce,
I manage the development of a widely used BPM tool which has recently been updated to include many case management features as we seen that this is a weakness in many traditional BPM products.
I agree with Danny in that the definition takes a document (or data) centric view of case management, however I have always felt that a more process centric view was equally if not more important.
This is an area I have been looking to get clear definition on for some time i.e. defining exactly what is meant by case management.
Below is some of my own thoughts and I would appreciate yours on process vs document centric case management or indeed even if you feel there are two different models.
Whilst the virtual folder containing all documents and or data objects relating to the case is extremely important. The process (and tasks therein) which make up the case and their inter-relationships i.e. to the data, milestones, roles, exceptions etc. is equally as important.
The key difference I have always seen between traditional process design and case process design (and deployment) is that traditional process design has always had a sequence or workflow pattern (even if these are optional steps etc. and adhoc design which we also support can permit steps to be added into the sequence) however when designing case there is no definitive sequence or number of occurences of tasks, and new tasks can be added at any point during the life cycle of the case as the need for these only becomes apparent during the life cycle of the case.
This then results in many processes which are interelated executing in parallel (each in their own right having a workflow pattern) but viewed and managed by the BPM as one entity utilising the same virtual folder, exceptions, data, roles, milestones and states. The case folder is then that information\documents etc. that is required to process these tasks rather than being the driver of them, i.e. a document receipt is not always the reason for performing tasks.
Sorry for the long winded comment.
Regards
Peter.
Hi Bruce,
I’m really pleased that you kicked off this discussion. As you may know, I’ve been trying to come up with a decent definition of case management. I think my reasons for trying to do this are a little like yours – having a category for software simplifies comparisons and enables me to highlight the less obvious differentiations.
I blogged a while back to test this dry description of case management:
———–
Case management is a paradigm for organizing, presenting and managing work items, documents, tasks and all information associated to a ?case? in a way that is contextual and meaningful to knowledge workers and general users. A case may be any short or long running component of work, or representation of a business entity, for example:
* Customer relationship
* Insurance claim
* Government agency services application
———–
Extending these thoughts, the key features of case management in my view are:
* Interaction or collaboration
There is a huge amount of interaction between knowledge workers, case information, structured process, research (i.e. information not formally attached to the case), decisions and history. Case management should facilitate this, pulling on tools and mechanisms from across many formal disciplines, including discussions, task management, document management, process and so on.
* Information organization
Organization of everything related to the work-item or case, be it structured information or content, is essential. The ‘virtual folder’ is a simple representation for content based systems, while it can become more complex, structured and organized for more generalized case management systems that present full casefolders showing many different types of information.
* Centralized view
All information that is meaningful to a particular user should be accessible from a single place. This enables case / knowledge workers to work within the context of the available information and the status of the case at any point in time. Typical collaborative applications don’t always manage to tie all elements together is a meaningful way.
* Decisions
Knowledge workers are the key decision makers, potentially backed up by automated rules and decisions. This is different from a lot of heads-down processing, where decisions are made through pure data entry and automation. Although many cases effectively become highly repetitive, its the way that information enters the case, from an array of documents and information sources of different types that requires intelligent human interaction.
* History
Every action performed needs to be tracked, not only for audit and compliance purposes, but because it can also be valuable to end-users that are trying to understand the history of a case over time. End-users need access to this history, in the context of what they are doing at a point in time to help them make accurate and informed decisions going forward.
* Process
Process for case management typically needs to be more structured than pure status tracking, but with the flexibility to represent ad-hoc tasks, exception handling, and completely unstructured sections of an otherwise complete end-to-end process. In my experience, case management processes often start out based on the need to track work and deliver it electronically, then grow. It is the ability to put structured workflow around the knowledge workers’ tasks that can help improve efficiency and accuracy, while reducing the total processing time for an item.
I’ve worked with case management at Vignette (from the Tower Technology software) which combined document and records management with lightweight processes. This was a tight integration of the individual components that focused tightly on content being king.
When I moved to manage the Global 360 Case Manager product last year, I found that Case Manager really lived up to its name. It incorporates a strong balance of structured and unstructured process and data, both captured internally and accessed through integration and SOA. It fits somewhere between BPM and ECM, though I have to say its heritage means that there are a very strong process and extensibility elements to it.
So my thoughts on what case management should be defined to include is probably skewed. That said, I believe it is the combination enterprise data, content and process, with the configurability and extensibility to apply itself to large business processes and problems that make it more than just an integration of a bunch of tools, and more than any particular industry specific application.
The last thing I want to do is create further segmentation between document-centric vs process-centric case management. It’s about consolidating use cases, not furher fragmentation.
The common thread here seems to be the unstructured nature of the process, or perhaps semi-structured. Case milestones and status exist, but the case as a whole does not have a structured flow governed by a process diagram. It seems there is a set of required and optional activities to complete the case, but others may be added by users at runtime. Also, the selection and order of activities to perform is left up to the experience of process participants rather than rules specified in the process design. In addition to documents and data added at runtime, tasks may be added to the case as well.
Does this capture the essence of case management?
I think you pretty much summed it up Bruce. I believe there are scenarios where either a process-centric or a content-centric approach is at hand. I was wondering (and look forward to implementing) how would a hybrid between both in the same business process look like?
That’ll be a sight to see. I’ll let you know how it went in case you’re interested.
Regards.
Hi Bruce,
I think it does capture the essence and its good to see that not just Singularity that have been struggling to get a clear definition. I also agree with phil_ayres in that if we can have categories for software then comparisons are may more straight forward, but also promoting capabilities within a product set and highlighting benefits to users become more straight forward and acceptable when its backed with clear definitions from the analyst community.
Hi Bruce, (et al…)
I agree in part with your thought that “Case milestones and status exist, but the case as a whole does not have a structured flow governed by a process diagram”. I think that for some scenarios this is true.
My experience is that Case Management represents an end to end business process that contains both structured and unstructured process components. Although the unstructured components of the process initially start off with just some status tracking and milestones, as they are refined and improved more high level structured process is often introduced. Being able to insert more structure over time is an essential feature.
Is all of this exclusive to case management? Probably not, and within the scope of a BPMS report maybe your description helps identify the areas of that are specific to case management components. My view has always been at a more complete solution level.
I do like your statement “tasks may be added to the case as well” is key to assist case workers in their domains of structured and unstructured processes.
What is the essence of case management in my mind? I think that Case Management:
…facilitates the effective and efficient processing of case work within end-to-end business processes. Case Management processes manage the introduction of work based on information or events coming into the organization, through decision making and collaboration, handling events and new information, to resolution and eventual filing of content and case data for recordkeeping purposes. Case Management utilizes casefolders to collect and organize structured information and unstructured documents, alongside tasks, discussion, history and external information. The casefolder interacts with process to provide knowledge workers a organized, consistent and contextual view of all case, content and process information.
Clear as mud? Useful?
Cheers
Phil
Something important to note, by recent experience:
Some companies may still hang on to the workflow notion of processes, including modeling of processes, and by that I mean “charting” them.
Implementing a content-centric engine (even when embedded within a BPMS) seems to imply re-educating and showing scenarios where typical workflow doesn’t cut it.
In our case, using the “Blind-surgeon” illustration was very helpful.
By the way Phil, it sounds intriguing how you might handle structured and unstructured process information within the Case Manager. The way I envisioned a structured process was providing precedence information, much like MS project does.
Another cool feature is mapping tasks to certain Case information, (in our case Services and their attributes), so that Tasks are “remembered” by the system. The next time participants are attending to a similar case, they’ll have likely tasks they might participate in. They could choose to add more tasks and change precedence, thus providing an on-the-fly “process modeler” (w/o charting) that impacts current and future instances of the “process”.
Regards,
I think a better way of looking at case management is to think of it as trying to reach a state, rather than complete a process. (Yes, I know that some process models rely on the concept of state–here I’m referring to the common assumption that a process is fairly linear).
For instance, my first project was a mortgage advancing system. It would take a mortgage application from the point where the customer walked into the bank to the point where the custoemr got his or her money. At a high level, the process was simple:
1. Validate the mortgage against business rules, and adjust the terms as necessary until all the conditions are met.
2. Once the mortgage is valid, send legal documentation to the lawyer.
3. Get the signed documents back from the lawyer.
4. Issue the funds to the customer.
Simple, but there was a huge amount of complexity buried in step 1. Every time the terms of the mortgage changed (which could happen without the customer’s involvement, for instance if the bank changed the mortgage rate) all the business rules had to be retested. That led to a number of process flows that would then be triggered off depending on which rules were violated–but they were all directed at getting the mortgage back to its “valid” state.
The cleanup process necessary to get the mortgage to a “valid” state was probably 80% of the work done by the users of that system, and every mortgage was different. But from a state-based perspective, it was conceptually very simple.
Very provocative comment, Kevin. Since one of my goals is to describe a list of capabilities for a BPMS that is good for case management, what might some of those features be, in your estimation?
–Bruce
[…] This post is my comment to the case management post by Bruce Silver. I couldn’t immediately register so this is where the post goes for now. […]
Andreas (comment #11),
Interesting comment. Yes you can use ad hoc subprocess to model a case in BPMN, but this does not really advance the ball, since the semantics of the case state as a whole are inherently absent. This might be true for some types of case management, but I think there are others – the ITIL examples come to mind – where you can describe this using message flows interconnecting the various processes of the case. In BPMN terms, a business process diagram (BPD) holds the case, but it consists of multiple pools (BPMN processes) linked by message flows. The choreography in a sense tracks the overall case status.
Having been involved in a number of case management-style projects, in my experience, case management is about the successful intersection (or unification) of a number of different technologies in order to provide a supporting environment that enables so-called “knowledge workers” to achieve an outcome. One technology ought not be considered more important than the next. Successful case management, when all of the tools and technologies are successfully aligned, enables efficient working. Lesser alignments are feasible, can still be termed case management – but yield much less efficiency for staff.
I think that the focus on “supporting” knowledge workers is critical – removing many of the mundane tasks such as tracking progress, managing and generating required artefacts, guiding them through critical aspects of the process – equally there is a need to support appropriate decision making by knowledge workers and support for external eventualities, i.e. events.
I often see the view expressed that process and case management don?t fit well together, or that “there is no process”, the reality is that you just need better process technology to cope with it. The solution in my experience, is that you have a number of well-defined processes – but that they can interact with each other – easily and loosely, for example through state management, data sharing across loosely coupled processes, inter-process synchronisation, ad-hoc initiation of processes, time-based escalation etc.
One of the other critical aspects of case management, in my experience, is the interaction with individuals outside the organisation, whether this is a party that a case may relate to, or other stake-holders in the case – this gives rise to the need for artefact management, and indeed artefact generation. As these parties are external – they often do not perform in a very deterministic fashion – again requiring flexible process capabilities to cater for this.
To differentiate case management from normal transactional systems I often summarise using these terms – who, what, where, when, why and how; case management systems are often used to meet requirements originating from the need to answer these type of questions.
Hi psoneill,
I completely agree with this, and think it should certainly be part of any good Case Management solution:
“The solution in my experience, is that you have a number of well-defined processes – but that they can interact with each other – easily and loosely, for example through state management, data sharing across loosely coupled processes, inter-process synchronisation, ad-hoc initiation of processes, time-based escalation etc.”
Does a commercial solution like that exist? Or, are you just bringing up the concept?
I would add, as we’ve been commenting, that you’d also need tasks not necessarily linked to a process with the same data sharing, sync, ad-hoc initiation and scalation, but at task level.
Also, what do you mean by “artefact management”, is it related to data/documents?
Regards,
Rafael
Also, psoneill, ¿how would you cover the need for on-the-fly creation of processes to include in your Case?
Sorry for the double-post.
To answer these questions – I believe that one of the key challenges from a BPM perspective in handling case management scenarios relates to the issue of “scope” (in the traditional IT sense). Thus data, roles, events etc can’t just exist at a single, linear process level, they also need to exist at a “case” level – and a case consists of one or more process instances, potentially running in parallel, which can share case-level properties. The other critical feature I believe is events for inter-process synchronisation within the overall context of the case.
I work on solutions derived using the Singularity Process Platform product – so a commercial product does exist with these features.
When a case is initiated it has case-level data (including a unique case reference), time-scales, events, states, exceptions and so on. Depending on the business problem being modelled – a case will consist of one or more processes, which can be “attached” dynamically to the case as required, by virtue of the unique case reference. Such processes have their own private scope – but they also have automatic access to the case-level data, milestones, states etc as these processes attach. Thus the individual case processes can operate on their own local scope and/or case level scope, e.g. fire events, wait for events etc for inter-process synchronisation, depending on the business problem being tackled.
In terms of artefacts – typically this can be documents, data etc. The emphasis in discussions always appears to be on receiving and storing artefacts, but I find that users also value the assisted or automatic creation of additional artefacts to be managed within the case – e.g. letters, spreadsheets, emails etc. Doing this provides a view of what has been both received from external parties and what has been generated internally in relation to the case. In terms of technology – I also find that XML provides a very useful way of dealing with data in a case environment – given its ability to “expand” dynamically, it provides the flexibility that is a common characteristic in Case Management scenarios.
Thank you for your response.
The Singularity platform seems to be very complete. Nevertheless, it appears to still require definition of processes before run-time in order to use them. That is not very different from other BPMS platforms, except for the fact you can “attach” processes on-the-fly. I think that IS a step in the right direction.
But, as long as there isn’t a way to define processes/tasks during run-time (I know it’s easier said than done), including user/group assignment, escalation rules, precedence for tasks, and very importantly some way to monitor the Case as a Case Manager (with the ability to monitor and edit all processes/tasks being attended to), we still have a very rigid solution.
What do you guys think?
In my experience, case management scenarios have a minimum set of processes that are required initially in order to get any useful system up and running. Over time additional processes are identified and added to the case definition, this is a normal evolution, as not all case eventualities can be envisaged at the outset.
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.
[…] Oldish threads sometimes take on a life of their own, and recent comments on a January post What is Case Management? have done just that. If you are interested in this important but mostly ignored corner of the BPM space, check it out. In addition to the G360 Case Manager product, it seems there is another product called Singularity that I need to know more about. […]
I was going to expand on my comment earlier before I went down most of the week with the flu. However, I think psoneill has covered a lot of the ground I wanted to, anyway.
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.
Kevin, in our industry -Telcom- it is a necessity to have the flexibility to add tasks (which could become “processes”, as I will explain later) as required in order to provision complex Converged Services. These activities could be assigned to practically the whole company, ranging from site surveys, provisioning on legacy platforms, local loop provider contact, adecuacy of site, conectivity tests, and so forth.
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.
I think I fall more on Kevin’s side of the fence here for ‘case management’.
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
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
I look forward to the definitive word from Bruce ….
David
Perhaps I should add a few elaborations to earlier contributions in order to answer some points raised.
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!
This has been a very enlightening thread. Don’t know if anyone is keeping track of it, but I found a couple of resources you might be interested in looking at:
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 .
Regards,
Rafael.
Oops, there was a problem with the links. Hope you can still visit the sites.
Regards.