There are both structured cases (where teh process is consistent) and unstructured cases (where the next action is difficult to preduct). The case management system requirements are very different. But most companies have both structured and no-structured cases and want one technology solution. That is the challenge for the vendors.

1.

[b]coming up with an executable standard[/b]

. CMMN 1.0 is in beta and just needs a final nudge to be done, so in itself it's not an amazing challenge. And it is easily integrated with BPMN.


2.

[b]creativity of architects in designing flexible case plans and event-aware case files[/b]

.


3.

[b]implementation of process mining tools[/b]

that create consistent case journeys out of multiple case plan instances and traces.


4.

[b]have the notation communicate well with customers[/b]

. Ok, this is for CMMN 2.0 - a big problem because case management notation is about flexible plans, event listeners, sentries etc. Relatively easy to execute, not easy to communicate in a graphic form.

As per the recent BPM discussion the biggest challenge to Case Management is complexity (design and integration). Complexity obviously results higher costs. This complexity is only going to get worse, not better as the number of business applications, formally and informally sourced, within an enterprise increase.


The classic Case Management market I think will remain the preserve of large businesses, an expensive luxury, with the lower end of the market continuing to be eroded by good enough, on demand, applications that claim they do Case but are in reality doing enhanced workflow.

I think the biggest challenge is, as stated above, the confusion that has been created in the market the last few years.


Every company manages cases, whether it be building a car, treating a patient or deliver insurance. Managing cases to bring them towards a desired end is daily business for a company in my opinion.


I think seeing all these 'things' as a case you do work for, is how companies should think. And for those cases, you execute a process. That can be straight through, that can be standardized, that can be batch oriented, that can be 'we don't know yet'. Those are just different ways of managing a process for cases.


Case management in itself is not a type of process. At least that's how I would like to see it. Unfortunately the term got many more definitions and meanings last few years. Quite a challenge...

Case management suffers from an identity crisis. Is it a subset of BPM? Is it an entirely different discipline? If my business (like many) has case-centric, flow-centric, and ad hoc processes, do I need two different solutions? Three?


Of course, some of the fog extends to enshroud the BPM world as well.


To be fair, this is simply how enterprise technology works. Business challenges rarely fall neatly into a single category, and therefore the clever CIO has to determine as best as she can where her company falls in the great Venn diagram of enterprise software solutions. If it were easy, anybody could do it.

If there is “Spectrum Of Process Functionality” then it should be something which is more basic than classic BPM and ACM. For me, this basic is coordination of work. Schematically, classic BPM is strong coordination and ACM is weak coordination. Ideally, the users should be able switch between different level of coordination (like with the gear box) without buying another tool with different terminology/practices.


Having commonly-agreed understanding which unifies BPM and ACM we can progress to


1) common coordination patterns and coordination constructs


2) better standards (actually, a coherent set of standards)


3) interoperated tools


Is it still a challenge?


Thanks,

AS

As many have indicated it is the vendor community that present the real challenge. Software must be able to support the inevitable complexity, structure and unstructured, and of course deliver that "Adaptive" capability.


To tackle this will require a top to bottom change in how software works and how that message is communicated to buyers. Analysts will need to dig deep be honest and truly understand "how" and not believe vendor marketing driven sound bytes.......and remove conflicts by not having vendors as "customers"!

Maybe Case systems came into existence outside of business demand. I mean, if we are seeing a tough sell due to both product and related service definition why even bring it up?


The reality is that the concept of "case" and its supporting systems are older than BPM.


Was the Case community left wanting for rediscovery and new polish? Or, did the BPM camp instead desire a campaign of conquest via re-writing an existing domain with a fresh, new ontology of their own making? Regardless of rational, BPM/BPMN should have been extended by merging case requirements into its notation. We might have had a holistic solution (ontology) to answer such problems as context-tunnelling and non-prescriptive work patterns. Instead we completely re-invented a model alongside supporting systems definition. Assuming this approach ideally sells more books/licenses. Unfortunately, this marketing tactic only created confusion in a somewhat boring storyline.


The BPMN standard lost its revision and now we have CMMN/Case-systems. Could have... should have... but didn't likely because the "not-yet-defined", or re-invented, case systems such as old FileNet and Global360 didn't feel the need. Their systems were in-production without this new "CMMN/ACM" fog and confusion - and their vendors didn't want to drag on pending sales with additional cycles to include yet-another round of "discovery".


So we now have an old-as-new CMMN/ACM domain and our customers struggle on the reasons justifying its attention.