As I have been working in the field for a while now, where both WfM and (Adaptive) Case Management (being derivates of BPM...) are being applied, I'd say the biggest challenge is understanding when to use what.
I notice (often) customers don't understand the proposition of both. So you get interesting situations where they want to build WfM type of solutions (e.g., a strict approval flow) using Case Management tooling etc. So... Confusion (again!).
It should be possible IMO to build a fundamental BPM (governed) framework (https://q9elements.com style) where you can anchor both (and more) approaches / tooling and put these in the right BPM context. I have done this in some cases and customers go like: Ahaaa... :-).
What matters here is that you understand how stuff gets done (e.g. the strict approval flow OR a more loose case handling situation). Only then you're better able to choose, decide and justify what enabler (approach, tool, resources) is the best fit...
I realize I didn't address technical challenges with Case Management Systems. But hey, that's also not my initial focus :-).
When to use structured versus unstructured, and HOW to do so. And that's always a proper understanding of the task(s) at hands and then the SMEs to go effect, implement it properly, including the BPMS and the technology.
I see at least two.
First, recognizing the markers of what is a Case Management type of process (or set of processes) vs. what is regarded as traditional BPM. Various markers have been proposed: process profiles (a set of distinguishing characteristics); dominance of structured vs. unstructured flows; use of structured data vs. unstructured data, or information as data vs. information as knowledge; clustering of sequence-drivent activity vs. event-driven state changes; degree of reliance on knowledgeworker; etc. I'd say all of these should be examined, but admittedly we don't have a consensus on whether an objectively measurable definition even exists (too much proprietary IP involved for that too ever happen, IMO).
Second, in a similar vein, we don't have a consensus on the vocabulary and semantics of Case Management as distinct from traditional BPM. CMMN has been put out there to make up for BPMN's limitations in modeling event-driven state changes across multiple process spaces. The vendor community alread moved on from this debate by ignoring/bypassing BPMN semantics and implementing Case Management semantics in their own idiomatic ways (making BPMN a new proprietary standard rather than what it was supposed to be, while turning discussions about Case Management into a Tower of Babel moment before any serious work could be done to mitigate that outcome).
Aside from that, I think we will see that more and more of what we regard as work is really more case-oriented than transaction-oriented.
The biggest single problem is thinking that it is "like BPM" and that means that you need a visual programming language. So many times I have see in effect: "Case Management is like BPM but you use CMMN instead" or "BPMN is for BPM and CMMN is for case management" as if that actually resolved the differences.
Some programmers will always be programmers, and they just really can only imagine the world in terms of programming languages.
Agree with Keith, as programmers said about 35 years ago: You may use Fortran, but you must not think “in Fortran”.
Recently, one of my clients has deployed an BPM application in which there are (almost) no flow-charts – activities and coordination between them are defined in MS project charts and a lot of linear (run-down) scenarios.
Again, flow-chart diagramimg is only one of the many techniques to make coordination explicit. (see ref1)
Case Management can be structured and unstructured. The issue is that people see no value in "modeling" the case flow. I believe that there is, but the level of detail that modeling will vary.
Most cases involve the customer, so first model the overall customer journey. This is the customer journey - not your internal process and how it impacts the customer which is what many mistakenly do, claiming it is the customer journey.
Then you can model the overall internal process that is interdependent with the customer journey. BTW "model" means end user / business modeling ie UPN-style (ref1) and not CMMN or BPMN. The level of detail you go down - heirarchically mapping - for these internal processes will vary depending on:
So the challenge is getting businesses to take the time to really understand the customer-related internal processes around the different styles of case they need to manage. The good news is that more companies are thinking about how their business is "digitized" and that means rethinking the business model and therefore the high level business process.
Can I get off my soapbox now?
The biggest challenge to case management "today" is what's coming down the pike "tomorrow".
Lawyers have woken up to a shock. And what's true of legal is also true of many case-oriented "professions" and occupations, including health care, insurance, field service etc. Automation also applies to you.
And the economics are fun too.
Standard BPM-automated processes (such as they are) are usually commodity processes by definition. So-called "unstructured work" with myriad exceptions and unknowns is typically where margins are found -- or costs are generated.
And "one person's exception is another person's lunch" (to coin a phrase I think). So that industrial structure evolves around who can organize niches of exceptions -- which then become more like STP for that startup.
And case management is at the center of it all. Competitive pressure because case management automation is possible. Therefore a startup.
The challenge for business leadership is new responsibilities for "thinking process" and "thinking automation". No more "wait states on the golf course" while IT codes a new idea. Case management and business process technologies provide business concepts as first class citizens of the technology. That means busness leaders, with a little help from business analysts, will be "at the rock face" of new process and case evolutions.
So business rushes ahead. Will BPM and case automation technology keep up?
Echoing many comments above, it seems that the biggest hurdles and challenges remain human-related, not technical.
Quotes from various actual ACM case studies published in the new book “Best Practices for Knowledge Workers” being launched at BPM and Case Management event on June 27. (Each attendee gets a free copy of the book, btw).
Maybe it's that business is confused at this "IT" term Case Management.....? All operational needs could be case management CRM the customer, SCM the supplier, HRM the employee, Grant management the applicant, Claims management the claimant, etc ....? What business wants will be the vital Adaptive capability to handle inevitable change and UI that recognises what the user needs for a good experience.
Then business wants to understand exactly what they are buying ...in their language and how it will address their specific requirements. This effectively knocks out hard code inflexible vendor versions of requirements! So it comes to the plaform that can handle all custom requirements both the formal and informal with audit trail who did what when to both contribute to supporting improving the process and of course satisfying compliance! So perhaps therein is the real challenge? And then who takes responsibility and how is this articulated to business so all are on the same page...a new experience for all?