The WfMC is hosting a discussion on “the kind of process support which is needed in order to support knowledge workers”. This has been called “Case Management”, “Dynamic BPM”, “Unpredictable Process Support” and even “Impromptu Process Support”. The point at this time is not to quibble over the name, but to get clarity on the concepts. Read the rest of this entry »
Case Management: OMG RFP released !
Last week, during the September meeting of OMG in San Antonio (TX), a new RFP has been released, under the name “Case Management Process Modeling”. This is a remarkable milestone. In this blog I want to reflect a bit on that, by looking back to what has brought us till here, and by looking ahead to what we can expect from here.
This blog is not meant to elaborate on the concept of case management itself. For the purpose of this blog it is sufficient if we just remember the concept as follows: A case involves a collection of activities or tasks. The process from initiation to completion of the case is not easily constrained to a process diagram. This is because the interactions are unpredictable and the focus is on the work to be done, not the process to support it. So which activities need to be performed in order to complete the case depends on the details of each instance. Furthermore, users can add new tasks, data objects, documents – even new processes – to the case while it is processing. Case management inherently carries with it fluidity of structure in an ad-hoc manner. A common component in systems that provide case management is the electronic case folder or case file. It acts as a single container for all of the processes, tasks, data, and documents for the case. The notion of a shared case file, as opposed to a routed process instance, gives case management the flavor of team collaboration as well. For more information, see the RFP.
Some years back, the company Cordys experienced more and more that customer projects do need more than just BPMN, in order to model and execute case management processes . Jon Pyke, chairman of the Workflow Management Coalition (WfmC) and former CTO of StaffWare (later on acquired by Tibco), entered the executive board of Cordys during that same period. This also contributed to Cordys’ awareness about case management significantly. Cordys started to pioneer, and released a new way of modeling processes, closely integrated with, but distinguished from BPMN.
Not long before that, Cordys became member of the Object Management Group (OMG). In the Fall of 2007, Cordys started some discussion with other OMG members, especially with Fred Cummins of EDS, now HP. Fred, fellow of EDS, and co-chair of the Business Modeling & Integration (BMI) task force in OMG, had hit on this topic independently. He also had the idea that standardization of modeling of some more paradigms of process management would be needed, in addition to what’s already possible through BPMN. He didn’t gave that the name “case management” yet. But when we (Cordys) started to speak about case management to him and others, he agreed that this is indeed the area that he also would like to dig into, and that probably the time has come to undertake that. He advised to present on this topic during the next OMG meeting, and so we did during the meeting of December 2007 in San Francisco. I remember that meeting as a very lively one, and right after the meeting we had interesting conversations with Derek Miers, Bruce Silver, Paul Harmon and others. Not all attendees agreed, but there were quite some that showed interest and support to take the idea forward. Maybe some of these persons do still remember that meeting.
The next step was to release an RFI, and Ed Barkmeyer (NIST), took upon him to write it. It was released during the March 2008 meeting in Washington DC, under the name “Dynamic Business Activity Modeling”. That name was not a very lucky choice however, as this suggest a field that’s even quite some broader than what uses to be considered “case management”. Even some of our customers told us that they would not immediately associate that name with the subject of concern. It was decided that, when it would come to an RFP and further steps, probably the name “case management” should be adopted. (Below you will see that this was not the last “naming hurdle” on the path towards the release of the RFP.)
Two companies presented an RFI response during the September 2008 in Orlando: Tibco (Paul Vincent) and Cordys. As case management actually is a very common business practice, and OMG hosts domain task forces in several “case management-intensive” industries, it was decided that it is important that BMI would team-up with these task forces, in order to prepare the creation of a business relevant case management standard.
During the next two OMG meetings, in December 2008 in Santa Clara and March 2009 in Washington DC, presentation and discussion sessions have been organized in cooperation with the Government (GOV), Finance (FIN) and Healthcare (HC) domain task forces. During these meetings it became apparent that there is clear application of case management in the businesses that they represent and that it is much wanted to cooperate on a potential standard. It was also concluded that there is clear potential synergy with e.g. the GOV’s new Records Management Services (RMS) standard, which includes a specification of case files.
During the meeting of June 2009 in San Jose, Costa Rica, there was a serious attempt to release an RFP, drafted by Cordys, but there were intensive discussions on several issues because of which the RFP could not yet be released, although it became already clear that various vendors would like to become submitters, in case the RFP would be released.
The discussion focused on the appropriate alignment to existing OMG modeling standards. Some believed BPMN is already suitable or would be sufficient if the BPMN 2.0 extension mechanisms were used. Some believed that UML would be a more suitable basis, given the fact that case data modeling and state transition notions are fundamental to case management. They suggested the use of a UML profile (using the UML extension mechanisms). The RFP at that time was a bit ambiguous on the dependencies on BPMN and UML. There was also discussion about the relevance of existing OMG rule specifications, such as OCL, PRR and SBVR. The relationship to BPMN and the need for consistency with BPMN were not sufficiently clear in the RFP, and revisions were too significant to be resolved last minute at that meeting. Therefore the vote was deferred to the next meeting.
The original RFP did also assume a rather tight coupling with the case file definition as specified by GOV’s RMS. The discussion, in between the June and September 2009 meetings, especially focused on that topic. It was decided that case management modeling must be compatible with RMS as a runtime service, but an implementation might choose other case file management implementations based on existing systems. Although RMS is relevant to be considered for any case management implementation, the RFP should suggest a more loose coupling with it. This triggered another issue, that probably the name “case management” was considered by GOV as a thing that’s clearly based on case files as standardized by GOV RMS. Fred Cummins then proposed, also given the fact that the famous European summer period was on, and time was running fast, that he would create a new version of the RFP, that relaxes several of these issues. The new version re-used some content of the old one, but brought a somewhat different twist. He also removed some fat from the RFP, caused by the fact that it originated from a white paper (note that transforming informational content into the OMG RFP boiler plate is a craft in itself, a craft well mastered by Fred).
The first attempt was to drop the name “case management”, while keeping its concept. The name “knowledge-driven processes” was suggested. That triggered a wake-up of many business-oriented people in OMG, and a lively debate over e-mail showed that, whatever would happen, the name had to be “case management”. Because this name is so well known in the business, cross-industry. There is no modeling standard yet in the world, but there is a very well recognized business practice called “case management”, and the potential standard had to recognize that. During this discussion it also became clear that there was quite some consensus now about the fact that a large variety of processes, typically case management processes, can’t be easily modeled in and managed by BPMN. So there is a gap. It came to a point that there were not many voices anymore that would like to argue that. If there would then be a way, acceptable to all interested parties, to phrase how the new potential standard would relate to existing standards, the release of the RFP would probably go smooth in San Antonio (September 2009) meeting. If, at least, sufficient vendors would support it.
Fred tried to word these relationships in a more neutral, open way. And I think he managed that very well. There have been several rounds of discussion during the San Antonio meeting to improve the corresponding phrases. During the week consensus was reached on that. Everybody agreed that the optimum was reached. It is not possible to be too specific, as many things have to be found out in detail by potential submitters. After all, when we compare the last version of the RFP with the earlier one, on this very aspect of relating to or re-using other standards, things are not that fundamentally different. But apparently most of the dust had settled and the air around the RPF had cleaned up much, somehow. A very constructive sphere had been created meanwhile.
And the very good news was that IBM decided to support the RFI, and to seriously consider to become a submitter. This fact is probably one of the most significant ones to make it an industrial success, and to give it, potentially, a reputation as good as BPMN itself has.
Several vendors are listed now as candidate submitters for case management. Amongst them are, in alphabetic order:
• Axway
• Cordys (Headquarted in the Netherlands)
• Fair Isaac
• IBM (related to their practice around both FileNet and Websphere)
• Pallas-Athena (Netherlands)
• Singularity (UK)
• Sword-Ciboodle (Scotland)
• Tibco (think about their business around, formally, Staffware, as well as their take on processes from the angle of rules and events)
HP, as service provider, will most likely also submit. Note that Fred Cummins, is a major driver behind the initiative. Also end user organizations do consider submission, e.g. Wells-Fargo.
During the San Antonio meeting Pega came to learn about the RFP and showed interest too. They are currently looking into the opportunity to become a potential submitter. Note that, in order to become a submitter a letter-of-Intent (LoI) has to be signed. Due date for that is February 9, 2010.
It has been agreed that, from now onwards, the task forces will look together for best positioning, synergy and integration of things. Such as case management (as solicited for by the RFP), GOV’s case file (as defined by RMS) and Healthcare’s HL7 specification of Electronic Health Record (EHR), and linked to the OMG thru the HC domain task force. It can be expected that establishing coordination between OMG case management and HL7 EHR is probably very opportunistic to do, given what’s in the air in the US around the Obama-triggered reform of healthcare! Most likely the new standard coincides with new business in new time era.
Practically, it is assumed that candidate submitters will start working together as a joint submission team. During the next weeks it has to become clear how this will be operationally organized. We are all looking forward to participating in this process and to work towards this successful new standard. We hope that many of you will embark on this new initiative.
Regards,
Henk de Man, Cordys
Tags: case handling, case management
If you go by the bmi thread on the renaming of the Case Management RFP — the new proposal is Knowledge Driven Process – it’s dozens at least. And the light bulb probably never gets changed.
Tags: bpmn, case management
I just finished a white paper on case management for Global 360, whose Case360 product comes the closest to my own view of what case management is all about. Click here to download the report.
Tags: case management, case360
In a previous post I describe the basic differences between case management and conventional BPM. This post concerns the limitations of BPMN 2.0 for modeling case management, and proposes some possible extensions.
It is important to distinguish the semi-structured behavior of case management from completely ad-hoc processing. By semi-structured I mean there is a case model, a design-time artifact that defines normal or typical case logic, such as the activities and information “required” to complete a case (or a phase in the case). Case management inherently allows ad-hoc behavior in that the behavior of a case instance (let’s just call that the case) can deviate at runtime from the case model. For example, the collection of activities involved in completing the case may not agree with those described in the case model.
The case model provides the structure necessary for documenting, understanding, and analyzing the processing and associated information objects involved. It is possible to conceive of case management without such a case model, but that is not particularly interesting from a modeling perspective. The issue is how to extend BPMN to serve as a useful design-time notation for the case model. This should not imply that the user’s runtime view of the case should strictly adhere to such notation or even use it at all.
As with regular BPMN, I would like to see the case model express as much of the “flow” logic as possible in a diagram intelligible to business. Hiding the logic in technical details invisible in the diagram should be minimized. At the same time, economy in the notation is vital, as page real estate is always scarce. I tend to favor a hierarchical modeling style, in which a top-level diagram provides a global view, with drilldown to detail in other hyperlinked views.
BPMN is lacking a number of concepts needed for modeling a case.
- A case is a collection of independent activities – both tasks and processes – not a single process. Attempting to define a case as a type of BPMN process is doomed to fail. On the other hand, simply modeling a case as a collection of BPMN process models does not capture the case as a whole as a single entity, which is crucial. BPMN has the notion of a collaboration as a collection of processes interacting via message flows. A case is a similar collection, but linked by different means.
- The case model describes a set of activities that must be performed and a set of activities that may be performed. (I use the term activity in the BPMN sense, either a task or subprocess.) The optional activities provide a menu of predefined tasks and processes that users can add to the case at runtime. In addition, ad-hoc activities (outside of the case model) may be defined at runtime and added to the case . In contrast, BPMN describes only the activities that are performed at various points in the flow.
- Process modeling in BPMN is based on orchestration, i.e., control flow described using sequence flows in the notation: When activity A completes, start activity B. In contrast, case activities interact through events. Extensions to BPMN’s event model could make it more useful for case management.
- Adding an activity to a case is not the same as starting it. BPMN sequence flow means start the activity. BPMN lacks the ability to add an activity to a case (or delete or update it).
- Documents (or more generally, information objects) are central to case management. A document has a lifetime independent of a case and could be part of more than one case. Thus documents should be stored and managed externally to the case instance and referenced by it. In the case model, documents of a particular type may be either required or optional components of a case, just like activities. The optional document types provide a menu of predefined types that can be added to the case at runtime. (And you could have in addition pure ad-hoc documents, external to the case model, defined at runtime.) Document state changes (created, updated, approved, deleted, etc) are events that commonly trigger case processing logic. BPMN data object is defined inside a process (or activity); it is like a variable. BPMN data store is much closer to document in case management, but has no notion of required vs optional, state change events, etc.
We should use to the extent possible existing BPMN 2.0 constructs. Useful ones include:
- Activity, either task or subprocess.
- Global activity (task or reusable subprocess). Defined once in the case model (or imported definition) and called in multiple places.
- Boundary event, interrupting or non-interrupting, meaning if this event occurs while the activity is running, trigger the exception flow.
- Escalation boundary event. On a User task this means “user action,” i.e. decision by task performer, what we sometimes call ad-hoc.
- Catching event in sequence flow, meaning wait for this event, then continue when it occurs; useful for synchronizing case activities (and external events).
- Throwing event, to communicate and synchronize with other case activities (and external entities).
- Ad-hoc subprocess. Here is how BPMN 2.0 spec defines it:
An Ad-Hoc Sub-Process is a specialized type of Sub-Process that is a group of Activities that have no required sequence relationships. A set of activities can be defined for the Process, but the sequence and number of performances for the Activities is determined by the performers of the Activities… Activities within the Process are generally disconnected from each other. During execution of the Process,any one or more of the Activities may be active and they may be performed multiple times. The performers determine when Activities will start, what the next Activity will be, and so on…. [The completionCondition] Expression defines the conditions when the Process will end. When the Expression is evaluated to True, the Process will be terminated.
The case model needs to describe more logic than simply the completion condition, and provide a notation for it.
In conclusion, I think we need the following elements in the case modeling notation:
- A container representing the case, holding activities and documents.
- A child container for subcase, representing a phase or milestone within the case. I’m not sure this is needed. Here is a possible rationale. Cases can be very long-lived. Sometimes they never end, just suspended and archived, and could be reopened at some point in the future. Each subcase may have a different set of required and optional activities and documents (but a single activity or document could be referenced by multiple subcases).
- Activities contained in case or subcase, either task or subprocess. Use solid boundary for required (in case model, can be overridden at runtime) and dashed boundary for optional.
- Documents contained in case or subcase. Use solid boundary for required (in case model, can be overridden at runtime) and dashed boundary for optional.
- Implied events. State changes on case activities and documents (or a standard enumerated list of them: onCreate, onUpdate, etc.) implicitly generate events, i.e. the “throw” does not need to be shown in the diagram.
- Boundary events on case activities , consistent as much as possible with BPMN standard.
- User action (Escalation event)
- Exception (Error event)
- Deadline (Timer event)
- Case state change (Conditional event)
- External event (Message or Signal event; Signal only if broadcast pub-sub type, otherwise use Mesage)
- Document state change (new type). Fuzzy line between this and case state event. This is meant to mean state changes in the doc repository, including metadata. If a document is approved, is that a document state change (in doc repository) or a case state change (i.e. “approved” for this case).
- Exception flow action conventions. Possibly shown as end events?
- Activity actions (add, update) – relate to activities defined in the case model
- Add ad-hoc activity (use tilde)
- Document actions (add, update)
- Add ad-hoc document (use tilde)
- Complete this activity in [state]
- Change case/subcase state to [state]
- Activity actions (add, update) – relate to activities defined in the case model
- Activity start conventions. I am struggling with this one a little. Any case activity by default can be manually started at any time. (Here “case activity” means top-level activity in a case or subcase container; activity inside a case subprocess activity is subject to normal BPMN rules about process activities.) In addition, I would like to show automated start in a convenient way. One possibility is something like BPMN event subprocess convention, i.e. use event type icon in upper left corner to indicate the triggering event, or multiple event if more than one possible trigger. These events are one half of a throw-catch pair, with matching throw modeled as exception flow end event (see above) or implicit case state event (not drawn). You would have to drill into the activity to see more detail. I need to think more about this one.
Scenarios and example diagrams to follow.
I view case management as a particular style of BPM, i.e., a class of business processes, that is not handled particularly well by conventional BPM tools. I am working on a white paper that goes into more detail. Below is an excerpt from the draft version:
What Is Case Management?
Over the past several years, Business Process Management Suites (BPMS) have matured into powerful platforms for process automation and performance optimization, many configurable by business-friendly process modeling tools. The benefits of BPMS over a wide range of processes – improvements in cycle time, throughput, resource utilization, standardization and compliance, business integration, and end-to-end performance visibility – are well established. However, an important class of business processes has been unable to enjoy them because of the limitations of conventional BPM Suites: case management. This report describes the differences between case management and conventional BPM and shows you what to look for in a true case management BPM solution.
One problem with case management is that no single definition for it exists. It has been variously described as a segment or style of document management, knowledge management, or customer relationship management. Certainly, document content, collaborative decision-making, and customer interactions are important elements of case management, but they are important in conventional BPM as well.
The essential distinguishing characteristic of case management is the “unstructured” progression of a case from initiation to its final state. In conventional BPM, by definition, a process instance progresses through a sequence of steps you can describe explicitly as paths in a diagram, leading from a single start point to one or more end points. The path logic for any particular instance might be determined by human judgment, external events, and business rules, but the steps, branching logic, and exception paths are all definable in advance.
In case management, by contrast, the flow logic cannot be expressed in such a diagram defined in advance. In case management, human judgment, external events, and business rules don’t just determine paths through a predefined diagram. Instead those factors determine at runtime which activities need to be performed and whether additional steps are required, either picked from a predefined menu or conceived on the fly. While this flexibility is an essential ingredient of many types of real-world processes, conventional BPM Suites demand a process model – however complex – that can be completely defined in advance.
Moreover, a case is rarely a single process in the conventional BPM sense. It is a collection of processes and isolated tasks, the number and identity of which cannot be fixed by a predefined template or rules. While case templates provide a convenient starting point for cases of a particular type, the actual steps and information required to complete each case are determined by a combination of human judgment, rules, and events occurring at runtime. While conventional BPM can sometimes manage individually the various processes involved in a case, it has difficulty managing progress of the case as a whole.
Despite its semi-structured nature, case processes suffer from the same problems as conventional structured processes. They take too long to complete. Resources are not used efficiently. Information is misplaced or not retained. No standardization across the organization. Difficulty of enforcing compliance with policies, regulations, and best practices. Lack of visibility into key performance indicators, either at the individual case level in real time or historical trends in the aggregate. BPM Suites bring relief for all of these issues with conventional processes. Case management processes need the same capabilities… but this requires a different type of BPM platform.
Who Uses Case Management?
Case management processes are a common occurrence in many industry segments, including government, insurance, banking and credit, legal, and healthcare.
Dispute Resolution
A good example of dispute resolution concerns billing and credit card disputes. Processing payments is a conventional structured process, but when a customer disputes a charge or demands a refund, case management is usually required.
Even if the credit card issuer provides a standard form for initiating the case, the activities required to resolve each case depend on a myriad of factors. What is the reason for the dispute? Were the goods delivered or services provided? Were they defective? Was the defect the fault of the manufacturer, the shipper, the customer, or some other party? Does the dispute concern the amount of the charge? And so forth.
Resolution of the dispute could depend on any or all of these factors, each of which typically involves production and review of documents. The credit card company may require information from the customer; the manufacturer, retailer, or service provider; the shipper; possibly legal counsel, attorneys, or even law enforcement. The rules involved could depend on the customer’s location. As the facts unfold, new tasks and documents may be added to the case.
In the end, there is no way to define in advance the credit card company’s dispute resolution “process” as an explicit flow from case initiation to resolution. But many of the same factors that motivate conventional BPM – timely resolution, efficient utilization of resources, compliance, and end-to-end performance visibility – are still important.
Other examples of dispute resolution case management include healthcare claims and grievance procedures, HR termination, and civil litigation and mediation.
Benefits Administration
Case management is well established in many segments of benefits administration, particularly in the public sector. Examples include disability, veterans’ benefits, welfare assistance, student financial aid, and grants programs. Within a single case there are issues of eligibility, disbursement of funds or services, changing circumstances of the beneficiary, reporting and compliance.
Underwriting
In various segments of financial services, including commercial lending, life and disability insurance, and securities, the underwriting process is really case management. The activities and documents required depend on the circumstances of each case. While the components of “standard” cases may be predictable, there are many exceptions, requiring additional input from lawyers, accountants, regulators, and investigators.
Project Management
An application area that could benefit from case management BPM, but has received little attention to date, falls under the heading of project management. Examples include launch of a new product or service, a major IT system upgrade, or mergers and acquisitions. There may be relatively few instances of a particular type of case, but each may represent high value and high risk. As with the other examples, the significant attribute is the fact that unanticipated tasks and processes may be added once the project is underway. Project management software typically provides just planning and tracking; case management adds the BPM dimensions of automated workflow, enforcement of business rules, and application integration.
Differences from Conventional BPM
These examples share a number of common factors. Some of them are absent entirely in conventional BPM, while others simply play a different role in case management.
Case Information Managed as Documents
A large fraction of case-related information is received and managed in the form of business documents rather than structured data. Where conventional BPM applies automated logic to data, case logic more often applies human judgment to information contained in documents. Thus a case management platform must include a complete document management system, a comprehensive facility for creating, capturing, indexing, storing, finding, viewing, sharing, editing, versioning, and retaining a wide variety of document types. Simple document attachments and a viewer, as provided by conventional BPM, are not enough. Case-oriented BPM should be able to apply rules to document events – check-in of a new version, for example – for automation and case status tracking. Just as you cannot predefine all the tasks needed to complete the case, you cannot specify in advance all of the documents required. While common ones can be required by the case template; others may be added ad-hoc at runtime.
Case Activities Added at Runtime
Some tasks and processes needed to complete the case may be defined in advance through the case template, but ad hoc tasks – whether selected from a predefined menu or defined from scratch – are a critical distinguishing element of case management. Often, those tasks are related to creating, obtaining, reviewing, and approving documents. Some of those tasks could represent conventional processes involving multiple participants. Managing a case as a single unit composed of independent tasks and processes – some added at runtime – is simply beyond the scope of conventional BPMS.
Case Advancement through Events
In BPM, an event means “something that happened.” Conventional BPM often initiates processes based on some event, such as receipt of a document, but from there the instance progresses like a train moving down a track. Subsequent events might switch the train to another track at specified points in the flow, but for the most part the process advances by itself. Completion of one task is what triggers the next one down the line.
Case management does not normally work by routing the case folder to the next task sequentially down the line. Instead it advances through events, both external and internal:
- External events include receipt of a phone call, letter, fax, or email related to the case. The contents of that message are added to the case folder, and new tasks or processes may be created.
- Internal events include assignments and business rules. Case workers assign tasks and initiate processes as they deem necessary as they work on the case. Business rules within the case may automatically create and assign tasks – or perform fully automated actions – based on either external events, completion of other case tasks, or expiration of task deadlines.
Thus, instead of a train moving down a track from task to task, the conceptual model of a case is a collection of independent parallel tasks interacting via events. Those tasks define the case context and are visible, along with case documents, from the shared case folder. The state of the case as a whole is determined by the combined state of all its tasks and documents.
Case Context through Shared Case Folder
Human judgment about advancement or resolution of the case frequently depends on not a single document in isolation, but the document collection as a whole. Thus, all case information – subject to specific security and access control rules – is typically available to users working on the case in the form of a shared case folder. The assumption that case workers know where to look for the case information they require represents the knowledge dimension of case management. In addition to case data and documents, the case folder provides shared access to case tasks and deadlines.
Why Case Management Is Hard for Conventional BPMS
As awareness of the case management gap in BPM has increased, BPMS vendors are beginning to add one or two features to their standard offering and declare it suitable for case management. But even with these isolated enhancements, conventional BPMS has a hard time addressing case management for several reasons:
1. The process engine. The key feature of a BPMS is its central orchestration engine, which automates the flow of a process instance according to a predefined process model. Some BPMSs have added the ability to insert ad-hoc tasks from another task in the model. But such tasks are not independent, running in parallel, with their own rules or possibility of spawning other steps from within them. They are simply grafted into the sequential flow for that instance. The fallacy here is that a case is not a single process. It is a collection of tasks and processes interlinked by events, rules, and business judgment. Conventional BPMS cannot manage such a collection as a single complex “thing.”
2. Content-awareness. Most BPMSs are designed to operate with data, not business documents. They treat documents as attachments, available for viewing, but they rarely support creating, editing, versioning, organizing, or finding the specific document types required by the case, or storing documents in large volume, or responding to content events, or retaining documents for years after the case is complete. Good content management systems can do those things, but they need to be deeply integrated with the BPM component to meet the needs of case. BPM Suites from content management vendors do this part reasonably well, but they tend to fall down on the next requirement.
3. The Case Folder. As the central feature of a case management system, one would think that an out-of-the-box case folder would be part of any purported case management feature in a BPMS. Not so. BPMS vendors are far more likely to propose that the tools used to configure the conventional process portal environment can be used create something like a case folder. Outside of the hassle involved, particularly in integrating the tasks, documents, rules, and events involved in the case, this approach misses the core idea of case management: a case is not just a collection of isolated things, like processes and documents, but a single thing that is progressing toward completion. That is what the case folder represents. If you cannot understand the status of the case as a whole through simple inspection of the case folder, you can’t really do case management very well.
Tags: case handling, case management
BPMN Case Management is intended to provide an informal forum for discussion about whether, why, and – most importantly – how BPMN 2.0 could be extended to better support the class of processes known as case management. It arose in response to comments on various posts on my BPMS Watch blog concerning Henk de Man’s Case Management RFP in OMG. This effort is not an attempt to derail that RFP, but rather an attempt to avoid the legacy constraints, mixed motives, and formal procedures that make progress in OMG or any similar standards body so slow and annoying. The goal is some good ideas, not a standard. Should some quasi-consensus emerge out of this site, I am confident there are other bodies that could take it forward to an actual standard.
Ground rules. Here are a few…
- We will define and discuss case management in the context of business process management. I think of case as a style of BPM that is not perfectly modeled by BPMN today nor automated/managed by “conventional” BPM suites. It is possible to conceive of case management in other contexts – document management, knowledge management, customer relationship management, vertical solutions for legal, healthcare, government, etc. But the focus here should be on case management as a style or variant of BPM.
- A major emphasis should be on notational extensions to BPMN for descriptive/analytical (i.e. non-executable) modeling of case management “processes”. That requires a basic acceptance of BPMN 2.0 as the basis for modeling conventional processes. If you hate BPMN as a conceptual model for processes, I don’t think this is the site for your case management suggestions.
- Phil Gilbert suggested a wiki format, but I have a lot more familiarity with Wordpress, which is a blog platform, so that’s what it is for now. I am the administrator, and I plan to invite a number of people who have expressed interest in this topic to be “authors,” i.e., authorized to create posts and pages. I believe authors can enable comments (or not) on their posts and pages. We’ll have to figure out whether comments are moderated or not. If you have an interest in contributing, please email me and you probably will be allowed to post as well.
- I’ve tentatively set up five categories. Administrative, for posts such as this one. Definition, for the topic of “what is case management?” Scenarios, for specific examples of case management “processes” where conventional process desciption (e.g. BPMN) is insufficient. Notation, for discussion of BPMN issues and proposal of notational extensions to support case management. References, for papers, articles, links, etc relevant to case management. Authors pick one or more categories for their post or page. When a category has more than 0 items it will show up as a tab on the home page. I expect other categories will emerge as we get going.
This post, or some evolution of it, will remain as the About page for this site. Any and all comments are welcome!
Bruce Silver