What is case management, and in particular, how does it differ from conventional BPM? A case, like a conventional business process, involves a collection of activities or tasks. However, unlike BPM, the process from initiation to completion of the case is not easily constrained to a process diagram, certainly not one based on a single end-to-end orchestration, even with complex nesting and chaining logic. Which activities need to be performed in order to complete the case depends on the details of each instance. Typically the case manager, or perhaps any performer of a task in the case, makes these decisions. The “rules,” so to speak, are inside users’ heads, not codified in explicit business rules.
Moreover, users can add new tasks, data objects, documents - even new processes - to the case at runtime. The “model” defined by the case designer cannot anticipate all of these in advance. Case management inherently carries with it some fluidity of structure or ad hoc-ness. This is the part that many BPM suites have a hard time with: New tasks, processes, and data can be added on the fly, but you still want the process engine to execute those processes, track deadlines for those tasks, monitor case status end-to-end, and even measure performance. It's not easy.
This discussion shows just how complex a case management use case can be. Applications that successfully implement a case methodology have to have many seamless components (content, process, metadata management), while being open and flexible enough to be extensible to a specific customer's requirements.
Its these features that I believe really make case management enabled systems very strong for addressing a wide range of common use cases in financial services, where a business analyst would otherwise struggle with a formal BPM approach.