Do you think it still makes sense to use a BPMS with no case management capabilities today?
You need to do both adhoc and sequential process in any end to end process. I would say "yes", but there are other forms of adhoc process besides case management. Ad hoc process capability is a must, but there are other approaches. Is it fair to call them "case management"? Goal directed flows can emulate the same behaviors as case mangement especially combined with content management engines.
If you are buying BPMS now you should get case management functionality with it. This functionality includes ad-hoc / non-sequential routing, document management (often done through integration with EDMS), correspondence management, and often letter template generation.
You can use BPMS for non case management processes as many processes are structured with straight through procesing of data.
First most, I think that some processes are a perfect fit for automation (workflow) and some just aren't. The thing is that business processes often are a mix of workflow (automation), case management and yes, manual tasks.
IMO it is therefore important to first grasp these beasts in the first place. Than you can decide how flexible your BPMS needs to be (ehrm... which is a bit of an oximoron...) and if it needs case management capabilities. Obviously we're talking technology here, and hey, my Kenwood kitchen robot is an all purpose system, as it is capable of executing quite some different processes. However, I probably might wear out some gears when I let it knead dough for 24 hours, or any other industrial continuous lasting process.
In the end I do believe that you need technology that is capable to both execute workflow, (adaptive) case management and manual tasks.
It all starts, as it should, with the analysis. What does the business need? If there is a need for case management (and I would say that probably 8 times out of 10, there is), then definitely get a BPMS solution that supports case management. But the question I have is if there is a cost factor in buying a solution with case management and one without? I am familiar with anumber of different BPMS platforms but I don’t really know the underlying licensing/cost for them.
Suppose there is a cost factor and a company cannot afford to get a BPMS platform that supports case management. I believe there are ways to replicate most of the functionality. I worked with a product that was mainly for high volume transactions but also had a very robust routing engine and customization layer. We were able to build a “virtual folder” with the product and that solution was very “case management-like.” Yes, it took custom coding to do it, there were limitations on what we could do and it certainly would have been a lot easier if the case management capabilities were built in but we said, “Hey, this is the cat we got. Let’s figure out another way to skin it.”
In general, the answer is "yes". But this is a conventional way of classifying the BPM space. The classification might make more sense for BPM geared towards developers. Another way to classify the space is BPM geared towards knowledge workers vs BPM geared towards developers. I don't think it really makes too much sense to have a product that spans these very two different constituencies.
For Knowledge Workers the way I think about this is that they need to start with something unstructured and familiar. Something like Conversational Processes (It's not surprising that many businesses run "processes" in email and chat as the Conversation is a natural starting point for processes). And then provide the ability for (optional) progressive structuring and integration. So rather than a combination of unstructured (Case Mgmt) and structured (traditional BPM) you have a progression from unstructured to structured.
Multiple instances without a priori Run-Time Knowledge has been known and out there for a while now. Not a BPMS out there worth its salt that can't address this, it's just how it addresses it and that has changed in recent years courtesy of rules engines. 'BPMS' and 'case management' are terms vendors and industry analysts have coined, and hyped, trying to (re-)make what's old as new, but the functional need has been there and been being addressed all along. It's just the 'how' that's changed.
It might sense if all of your processes are end-to-end.
This covers fully automated industrial processes (not typically discussed under the BPM umbrella). It covers some of the work that takes place in office/services (again, end-to-end where you can conveniently park objectives at the end merge step)
BUT, once you go over a certain threshold in terms of the ratio of ad hoc interventions to structured interventions (starting at 5/95% and moving toward 95/5%) you get to where objectives need to move from plan side to run time side and here you need the following:
1. BPM to assume a background role in providing orchestration.
2. Case (or some other run-time environment) for hosting the performance of work and providing governance.
a) accommodating ad hoc interventions (with rules to "rein-in" extreme unwanted excursions away from best practices).
b) hosting goals/objectives whilst providing tools for assessment of progress toward objectives.
c) providing RALB (auto resource allocation, leveling and balancing), so that you have workload management as well as workflow management
d) accommodating real-time streaming of data to a history (to provide an audit record on work performec AND for real-time decision support at current structured/unstructured steps).
e) accommodating semi-real-time streaming of the same data to a Data Exchanger for 2-way flow to/from local and remote 3rd party systems and applications.
(can anyone identify other missing capabilities?)
Once you shift the focus from traditional BPM to Case, many practitioners (and their clients) find it perplexing to hear management say. . .
“Here is an inventory of best practices we have spent a lot of time and money refining. We can prove that consistent use of these takes you to improved outcomes”
“Feel free, where practical and practicable, to skip steps, revisit already committed steps, record data at not yet current steps, and insert steps not in any of the templates”
Without Case to host the performance of work and provide real-time governance preventing extreme, unwanted excursions away from templates, you lose the ability to manage work.
So, unless all of your work is end-to-end, my contention is no, BPM will not work without case management.
BPM assumes processes. - in knowledge work you no longer have processes, what you have are process fragments that knowledge workers, software and robots thread together at run-time.
We spent a few years on the sale pitch for ACM – the model that seems to work is that of a two-lane highway where the center line provides guidance (orchestration) and the railings on either side are guardrails (governance).
Logic and rules from BPM flowgraphs provide the orchestration, rules at the Case (“reining -in” extreme, unwanted excursions) provide governance.
All depends, as usual. And a decision algorithm is below:
1. Consider that coordination of work requires several coordination techniques – see ref1
2. Understand what level of which coordination techniques you need (now and, may be in future).
3. Profile a BPMS and a case management tool for their level of support for those coordination techniques – ref2
4. Find the best match.
Hmmm, is this a boring question about product functionality? Or something larger? And even at the core of what BPM is all about?
Mr. Lujan alludes to the difference between ante-to-play BPM functionality and important ad hoc-capability-that's-easy to use. The difference explains a lot of the challenges around BPM technology adoption. Because a priori our knowledge of work patterns is less than we think, and even "contested terrain" in the sociological sense.
The Platonic fantasy of STP ("straight through processing") on which a lot of BPM is sold is a disappointment waiting to happen. Behind the scenes is the reality of work, where "tacit rules". Work processes, especially with the addition of all-important exception handling, are inherently fluid. (We could extend the metaphor to categorize fluidity as ranging from "viscous" to "like water" . . . )
So now we call ad hoc adaptation "case management", and it's a good way of thinking about processes. The question of case capability however might be thought of as an artefact of a time when BPM technology was less capable.
Today, a better way though is to start from work for which an automation business case can be built, and then apply BPM process tools complemented by rules and algorithms. All-in, full court press. The technology is up to the challenge now, for all work patterns, including case. It will take a lot longer for governance to catch up.
As said above, most BPMS's have some ad-hoc execution capabilities, as long as they stick to the BPMN standard - since BPMN itself includes to some extent such patterns. It's just that very few people use the BPMN standard to its full potential. There's even a trend to use as little as possible of the BPMN standard with the hope that this gets picked up by non-developers and everyone models just about any business process only with tasks and XOR and parallel gateways (I'm not holding my breath till then).
An interesting case (pun intended) is made by Jim. We had long debated, for some of our case management customers, how deep should we go with CMMN, provided that there's very few reliable engines and even fewer good modelers that are compliant (and the old ones tend to be proprietary, aka aiming for tech dead-ends).
We decided to put CMMN on the back-burner until tools mature. Turns out we could do most of the stuff with the content management features of our portal tech. Not ideal, but not very challenging either, with the right design mindset.
Sure! Although we're finding that the knowledge-worker workflow is extremely common and useful in imagining these applications, case is still not one-size-fits-all.
However, what is a mistake is deploying BPM and case separately. If you've got one platform for case and another for BPM—or even one product featuring dissimilar viewers, builders, or reporting for each model—you've made things harder than they have to be. One solution, organically uniting both approaches, provides you with a comprehensive toolset with which you can address any business process/application need. More choices, fewer compromises.
I think this question raises the confusion for business people in relating to what IT does to help business. The inside out drive by vendors with hard coded applications all with different tags CRM,SCM,HRM,ECM, etc all sitting in silos and what a mess......In reality are they not all "Case Management" and should be joining up with the outside in approach which is where the discipline of BPM sits? Think about it business basics are selling and buying in some form or other with people as the important delivery asset.
As for BPMS well what does the S stand for.....was Suite i.e. a hard coded applications selling the vendor ideas how to work? Or is it now System or Software? The supply chain just loves such confusion as do analysts; keeps all in a job! Fact is business is really quite simple it's about people who create information and need basic support to receive and record data as required. Research has shown there are less than lucky 13 work tasks including links that can address all needs.
It does not matter where you sit in the business these generic task types fit all. So the outside in thinking can start with the help of BPM and quickly create the optimal solution direct from user input. Surely this represents the way forward but with the tag Adaptive to highlight the capabilities to both adapt to specific user requirements and of course supports change as circumstances dictate. I doubt the relevance of tagging it with BPM yet that discipline is important to get thinking right and business people on side.