Can't see the need for "Case Management Notations".
For us, a Case is just a "bucket" that hosts workflow/workload and auto-builds a history.
You can call structured BPM "process fragments" from within a Case, insert ad hoc interventions (processes of one step), attach documents, files, images, video/audio recordings . . .
As for the value of notations/languages for business process managment in a BPMs, several members in our group transitioned over decades from deterministic flowgraphing (CPM), to CRM, to workflow/BPM and from there to ACM/BPM.
We worked in manufacturing, heavy construction, data processing, securities trading, aviation, software manufacturing, and management consulting, with the following observations:
Our basics are nodes, directional arcs, plus a few "complex constructs" such as lassoing two or more nodes to build a branching decision box; putting escape counters on automated loopbacks etc.
For really complex processing needs (i.e travelling sales, medical diagnostic algorithms), we prefer to build and link to specialty apps to avoid rolling out bloatware where no customer uses more than say 5 % of all of the "features/functions".
On the topic of Case Management, our view is that Cases are managed by Case Managers.
Several methodologies, one being FOMM (Figure of Merit Matrices), greatly simplify Case Management (reducing subjectivity from progress assessments). Fortuitously, ordinary spreadsheets with a one-page instruction sheet allows Case Managers to implement FOMM.
Putting a good Case Manager in charge of a Case seems to have the greatest impact on improving outcomes.
Well...the anti-modeling crowd has been heard from. I've never really understood the thinking behind those who are so dismissive of modeling and the need for standards-based modeling languages. Generally speaking, the usual arguments - about moving the tacit to the explicit, supporting reengineering and/or automation, facilitating interchange between domains, yada, yada, yada - never seem to move them off their fervent belief that it is unnecessary. With respect to that crowd's perspective, I would suggest Peter open up a different thread where for that discussion. This thread is intended to air out the CMMN vs. BPMN debate as to which is better for modeling case management situations, as a follow-on to the two papers that Anatoly and I have published elsewhere on the site. FWIW, I do intend (later today) to summarize the extensive back-and-forth between Anatoly and myself in order to help frame the discussion, and, if necessary, jump-start the thread.
While I was at IBM, we extended the Event Driven Activity notation in BPMN to be able to express Case work patterns quite effectively - Those are now a standard part of IBM's platform. CMMN provides more clarity when the majority of the Activities are Ad Hoc, but you could live without it.
What we learned from adding "Case Like Work" to the BPMS was that it's the End User's View that is the true differentiator between Case and BPM. In BPM the users typically work from a list of Tasks, in Case they work from a holistic view of the instance that aids them in deciding what needs to be done next.
That's the frontier we need to focus on - Defining the appropriate interface for the workers in a more declarative way.
As others have already mentioned, a case is a repository of meta data that is workflowed around the organisation. The vast majority of the case management implementations fail due to the lack of the end-to-end process capture of the what is required pre and post the cases being managed. If you think that BPMN will be the answer to that problem then you are very much mistaken. What is needed is a fast, easy to use, easy to understand notation that is created and understood by the case workers. BPMN is defintely not the answer.
However, you do raise an interesting question and that is do we need a case management notation? Well, the answer is still No. So the question is, "what do we need to ensure that the end-to-end process where cases are managed and workflowed as part of the process?". As an example, in the legal sector, where cases are known as matters, the Partners of the firm run and manage their cases in many different ways and the downstream case teams need to be agile and flexible to support the many variations of workflow. Do you think that a Partner in a Law will engage in a Case Management optimisation workshop where some consultant is using BPMN? I don't think so!!
So, the answer is simple - but you need to be a true process professional and a leaderto understand why this is the answer. The answer lies in embracing the new kids on the block. If you haven't checked out Skore Labs then you are just living in the past. This is where the answer lies.
By definition, debates "CMMN vs. BPMN" are endless because there is no BPM architecture. Let us have it finally. Otherwise the BPM community may lose good opportunities - see ref1.
Hi all !!!
Thinking in "be simpler" to be "efficient" ....
Thinking that current version of BPMN offers artfacts that are able to represent "Case Management"
Why work in another notation to represent something that is part of business process?
I'm favor to explore and use BPMN.... or any other that is capable to represent business process and his universe.
Otherwise, We have to work in 3 levels of notation for many of our process and bring complexity for the effort and for the business process management:
And the question would be Which values these will bring for the business?
Maybe CMMN can be used in very critical business process...but if currentlymany organizations does not have many of their structured processes managed and modeled, how to advance for complex decisions?
Short answer: You need context, context and context.
With regards to notation, this depends (as always) on your audience. If you need to create a case-type definition, representing the objectives of that specific case is pretty important. On the other hand I regard BPMN or petri-nets as a technical notation for a technical audience. Meaning that carbon life forms probably won't read / understand it. And as that happens, any notation that cannot bring the message accross, is missing the point.
So basically I wouldn't care much for yet another notation, unless it is able to address all audiences in one go :-)
Al models are wrong but some are useful said Albert Einstein. Both BPMN and CMMN are not useful for the business people who are supposed to create the cases and processes.
Business people want business language and nothing else. Their notation musst be a context sensitive rule language editor in which they can define and execute commands, write decisions and describe goals and map variable data in a simple syntax. The graphical notations are ok for techies doing complex GUI and orchestration.
We use an ontology to enable well defined business terminology including constraints, validation and conflict resolution.
We take it a step further and use that to describe the business architecture that is the basis for objectives, targets and goals. Business users can describe their user interactions in well-structured user stories that can be actually executed ...
All other modeling will simply go the way of other non-user friendly stuff ...
First: I am a big fan of a simple task list. Eveyone knows how to use it. There are huge, multi-million dollar projects that are run on check lists which provide everything needed. This is well proven territory.
Between the fully imperative modeling style of BPMN, and the checklist, there is room for a declarative modeling style that states what can not be done (excludes certain transitions) but otherwise allows anything else, including doing nothing. Offerings in this space:
1) CMMN gets a lot of air time but not the only game in town
2) DECLARE is a graph model languange that offers flexible and intuitive partial sequencing of activities. Yes, it includes arrows.
3) DCR Graphs - (Dynamic Condition Response) has arrows that enable activities (like guard conditions), as well as arrows that can DISABLE previously enabled activities.
4) SCIFF - a formalism for declarative programming describe as allowing abductive expressions which some say better represents social interactions.
5) BPMN-D is a declarative extension of BPMN. Best of both worlds! Maybe....
6) Coloured Petri nets - probably not friendly enough for business users, but stands on a rigorous formal foundation.
Of al these, I have seen DCR graphs applied to real world problems, and the results feel quite natural and readible. Are these necessary? Hard to say. People have a natural tendency to reduce problems to (sometimes) oversimplified forms (the reductionist falicy) and give that there is a desire to automate in an attempt to avoid what is seen as unnecessary complexity.
But we should start with a checklist, and only when we find a problem that can NOT be met with a checklist, only then consider declarative programming models.
There is a need to be able to communicate the totality of an application (process, data, rules, etc.) to the business. That will always be a huge challenge, because the people doing the work typically don't share a mental framework with the people analyzing the work.
Notations are an admirable attempt at bridging that gap. But, having spent over a quarter of a century happilly married to a technology-challenged musician, I can attest that fundamental differences in ideation can be awfully hard to reconcile.
There's a joke: a businessperson, an analyst, and a BPMN consultant are visiting Wisconsin, and happen upon a field, wherein they observe in profile a single black cow browsing in the tall grass. The businessperson says, "I guess the cows in Wisconsin are black." The analyst replies, "Well, at least one cow in Wisconsin is black." The BPMN consultant testily corrects them: "All we know is that there exists at least one cow in Wisconsin, at least one side of which is black." They stare at one another in confusion for a moment before deciding to get the hell out of there before the taxonomy consultant comes along and tells them that what they saw wasn't even a cow to begin with.
I hope that clears things up.
Wow, everybody riffing on this one. There is no doubt that BPMN semantics can handle case management, as John Reynolds and Anatoly have demonstrated, Virtually all BPMS vendors have taken this approach because a) their BPMN engines can already do it; b)the spectrum from structured to unstructured process is continuous not binary; and c)what user in their right mind wants two languages and two engines when one will suffice? For that reason, it is pretty obvious to me that CMMN will never achieve liftoff. Lloyd may have the spec on his side re official BPMN operational semantics, but honestly these fine points are in the parts of the standard that BPMS vendors ignore anyway in the effort to build something that works.
You can use event subprocesses for case models, or as Anatoly does, independent processes coordinating state via messages and shared data. The problem with both these BPMN approaches and with CMMN, "simplified" or not, is that the diagrammatic representation is not particularly helpful in depicting what is going on - where things start, where they end, the general flow of getting from here to there. My own takeaway from bpmNEXT, where we saw many different ways to attack case modeling, is that Scott Menter's Process Timeline approach (basically a Gantt chart) is a more useful representation than any of these standard notations. I'm surprised he didnt mention it. Or maybe he was just being ultra-subtle.
BPM is the technology of work automation; at its core is process language, or more specifically at this time "technical process notation". The fact that these notations are currently inexpressive for the purpose and aggravating for managers to use should not be seen as anything more than technological immaturity. There's a huge win waiting for whoever can deliver the business process management automation technology that business needs.
Practitioners, engineers and theorists circling the elephant and each identifying an important facet of the meaning of the thing.
And what is the thing, but the technology of the automation of work, i.e. where the concepts of work are first class citizens of the technology. And this is a statement which is by definition only true of BPM technology. And from a business and sales perspective, BPM should therefore be pretty important. And likely more successful than it is -- except the technology isn't yet sufficiently expressive and efficient to match the need or the rhetoric.
If there is to be a fruitful discussion about the development of BPM technology, one must consider the science on which the technology is engineered. Ontology is usually the term that comes up, and only @Max has mentioned it, along with the idea of "business language". (All other references to language are to technical languages.) And @Keith has mentioned graphs, which are also science, i.e. mathematical formalisms, which may support highler level human-friendly business and work languages.
I have previously compared BPM to accounting and finance. All business people, in greater or lesser degree, do accounting and finance, as a matter of course. And accounting theory, practice and tools are available to help them do this work faster and more accurately. There's no quibbling about "models" or "notations" or "round-tripping" or "waiting a month to change a chart of accounts". This is the future to which BPM technology will evolve.
At time "x" in the future and like accounting and finance, BPM will also be part of common business technology; all business people will use BPM as a matter of course. The technology will support "task automation for which what you draw is what you execute -- immediately, in flight". Underlying future BPM technology will be expressive but invisible notation that easily supports just about any way of working. If it makes sense to perform work in a given way, then technology will exist to help you do that.
In the meantime, there should be no "modeling or anti-modeling question". Technology and language by definition concern abstractions. There are just inadequate languages which most business people find unsatisfactory. And so today, the business process management is often still not fully automated, and the sufficiently expressive language used by managers for process management is just the spoken and written vernacular.
The goal of powerful BPM automation technology, widely adopted, is becoming easier to imagine. And in some cases, the future is already here -- but, as William Gibson said in 1993, "it's just not very evenly distributed yet".
I disagree heartily that BPM should be about automation. Process management is about automation diagrams but add 'business' and it is not. Yes, it is today about automation but that does not make it right. It rather shows the people doing it quite shortsighted and inept in understanding what a business is about. In fact a business is not about processes at all. A business is about collaboration and it ought to achieve well-defined goals that produce the target numbers defined and follow the larger business objectives layed out in the strategy. Automation in human collaboration does the opposite of what it is being sold for. It does neither make it cheaper, nor does it bring higher quality from a customer perspective or make a business more agile. These are empty claims that anyone with somewhat of a business acumen knows them to be. It gets even worse when experts are needed to define processes and even they have to follow a complex methodology to make them work, just like the business has to go through a 'culture change' to make BPM viable ...
Is anyone proposing all that even listening to what they are saying? It is highly unlikely that any of that will have a long term impact and much less pay for itself one way or the other. And that was the very clear message consolidated from the discussion in our last management seminar by the participants. BPM is too complex (both methodology and tools), to expensive and kills agility and creativity and reduces customer service quality in the mid-term. Yes, the checklists that Keith proposes are kind of simplistic goals and goals defined in cases go a long way. So there is a direction that will flourish.
BPM (or whatever it will be called in the future) and its proponents will only survive if they step out of this arrogant attitude that BPM is the silver bullet. Actually most companies who don't do BPM do pretty well if they have a customer service attitude. There isn't a business that has been saved by BPM. How much BPM is REALLY done? 3-5 percent of what a business does is at best implemented and over time the processes are amended with bypasses and ad-hoc external fixes to keep them alive.
The key for applications is after all is usability and user-friendlyness and in fact customer service friendliness. BPM driven, rigid customer service is not good and certainly not better than a service clerk with a good attitude. So yes, BPMN is about automation and we also use it for that but it is not about business process. BPMN is another form of application coding and it needs experts. I find the discussion about BPM or ACM or BPMN or CMMN so missing the point and a waste of time. Ask the companies and experts who recommend a business to use BPM methodology and automation how much of their business is run like that and there you have your answer!!!
And finally, there still aren't any independent studies that prove that large scale BPM works. Vendor and consultant success stories are so-called anecdotal evidence. I have proposed a mathematical proof of how difficult it is to make processes work in the large scale and not a single expert has responded. Why? Because they know I am right. When 500 linked processes are 99% right then the probability that the whole business will work right without human intervention to correct problems is just 2%. And now you hear that processes just need to be 80% right ... so much for automation!
I guess the question is, is CMMN the screwdriver to go with your BPMN hammer? Or is it just that one odd sized philips screwdriver that you really don't use except the one time you bought that self-assembly cabinet from Home Depot and had to buy the right sized screwdriver to go with it?
Team Craft, in the person of an able champion, Mr. Pucher, has strongly articulated a view of business-friendly software technology. And certainly business can use more business-friendly technology! The concerns from Team Craft regarding BPM software, including "complexity", "expense" and "inflexibility", are serious concerns indeed.
This view of business software technology is what might reasonably be called "the craft view of technology".
One expects however that over time the "craft view" of business technology will become progressively less useful.
The social organization of work according to craft is typical of early stages of technology. There is a significant and important social element (often managed by guilds) to craft technology. As time passes though, craft technology inevitably gives way to codified and industrialized applications of technology. And our standard of living today is in part the result of this process.
What is this new generation of technology where software is concerned? Software technology deployed not as craft, but as industrialized technology? It is all the categories of modern software, including ERP and industrial controls -- and BPM. And all this software concerns the automation of aspects of work.
As implied by the root word "automatic", automation means the use of technology artefacts which perform work "by themselves". Typical definitions of automation focus on control systems (i.e. found in factories, or as a thermostat for example), but this perception is unnecessarily limited. All software and especially business process management software involves automation.
For example, popping a task from a stack of todos in a basic workflow system, and having that item show up in the stack of done tasks, is automation.
(This more general idea of automation shows up in the growing category of "robotic process automation" ["RPA"], which is the new generation of software-formerly-known-as-screen-scraping.)
So, by definition, BPM technology concerns automation.
Software is a force multiplication technology for human endeavour. And software, including software-technology-as-craft, can contribute to the achievement of human goals. But it's even better when we can figure out how to scale software, especially BPM, for even more productivity. And more achievement.
To champion software progress is not to denigrate the achievements of today. Craft technology of any kind always has a sort of romance to it, and is often associated with an affection for what is uniquely human. Not a bad thing for sure.
On topic: BPMN with certain logical extensions (right now you have to overmodel it a bit to make it executable, see coordination of MI sub-processes via signals accumulated in payloads) and with a bit of old school architecture around it can fulfill any case management use cases.
My grief with CMMN is how the model is actually obscuring the behavior of the case, rather than revealing it. When I show a litigation case plan to some lawyers, they just emit alpha waves. As soon as I finish explaining the case, the same questions arise again: "what's that sentry do?" "so how do you actually complete the case? what are the conditions?" "how do we model - don't do this?" "what are the case files for this scenario?"
CMMN is not that hard to learn - but what's the point? So, yeah, I'd rather just extend BPMN to properly cover cases.
So, here is BPMN semantics-level rebuttal to Anatoly's model. But before going there, I want to thank him for his focused treatment and insights, and to his credit, for catching me on missing the use of Collaboration to model case situations. Having said that, there are still limitations with that approach, as shown below. And for those who are brave enough to get down in the weeds wth me on this, only referenced arguments based on the BPMN specification will be considered germane. In other words, find another thread if you want to promote your product.
- Use of process name as the pool is a known sore point between those who read the spec as it is (see p.112), and those who read it the way they think it should be. FWIW, I’m sympathetic to the arguments advanced by the latter, but I also see the wisdom in understanding a pool – as a visualization of a participant – as an organizational (or system) concept which essentially defines a span of control over any process contained therein. Those that find this an inconvenient thing, and so respond by ignoring it or decrying it as just an “academic” thing, are just being willfully resistant to considering the other point of view. Anatoly’s use here is clear, namely that it is the same organizational context, so I can look past the pool naming issue. However, we have fractured the E2E perspective of the modeled behaviors that is in effect shared across that context by those very processes. I posit that this is lossy with respect to the CMMN representation (not to mention a bending of the basis for comparison since the point of the comparison was for the single model view). Also, even though I teach Collaboration as well, I have found it a challenge to get folks to use it or at least to use it correctly. It would appear that Anatoly and Bruce have been more successful, and that informs their preference, and I commend them for their successes.
- Anatoly’s use of the data store to show the capture and retrieval of state is both elegant and informative, but it is a slight bending and distortion of the spec because it is used in more than one process as opposed to used “in one or more places in the Process” (see p. 208). (I found that one modeling tool wrapped a “fake” process around the free-standing data store, which allowed the data input associations and data output associations to still work, but referenced the data store ID rather than a data store reference ID, which is what would otherwise be expected.) The fix to this would be to show it within each of the referenced processes, so we could consider this a semi-legal short-hand approach to diagramming. However, it is nonetheless, a re-interpretation of what is there, which would support my point that the spec is not sufficient. It also reinforces the notion that state can be shared between processes this way, which is not really the case with this use. The data store can persist state beyond the scope of the process, but it still must be introduced into or pushed out of the scope of any process, so the awareness of this state is not knowable by a process instance until something in the process has made it so (see p. 224 for a description of data input association and data output association work with any item aware element in the process scope).
- The always confounding use of Data Input and Data Output can reference Data State outside of the BPMN spec, allowing “adopters” to use and/or extend it (see pp. 213-215). But aside from having to explain the semantic difference between these and Data Objects used as inputs and outputs (not an easy task), means that vendors work it outside of the spec by using and/or extending the Data State element. Problem, as I see it, is that this is an acknowledgement of the spec’s limitations regarding data, proving my larger point, and, worse, I don’t know of many vendors that actually do this – and I mean uses and/or extends the specific element – as opposed to implementing it by some other means.
- A Collaboration is NOT an element with scope characteristics (see p.281), so this usage – despite its seeming clarifying use in Anatoly’s model – is not really correct with respect to the spec, which again proves my point that it is too limiting for full-bodied treatment of case-like situations. The fragmenting of scope that is thus realized through the use of Collaboration forces the modeler down the same path I had to tread – namely, synchronizing actions with state across multiple situations. For example, in Anatoly’s example, he wants to allow the process to enable a performer to come in and terminate the “case” but there is nothing in his narrative that is modeled in his BPMN to show how this would be known or occur (it is merely asserted), whereas the conditional event in my single process view of the baseline process does this – as does my CMMN model with its ifPart component for the terminating user event. Anatoly’s Collaboration is missing several triggering events (or, more precisely, appropriate event types) that would be necessary in order to assert a true equivalence to what my base BPMN model shows as well as what my CMMN model shows. Once one corrects for this, the diagram is more complex than it was before.
- There are other examples of lossiness and looser semantics. By moving the terminate function to a separate process, as opposed to leaving it as an event subprocess, it cannot share in the scope of the main process, and can only terminate a process instance by the use of the other, parallel thread at the start that leads to the terminate end event. While the terminate end event is not really exotic, I find its use in the wild quite rare, and often more associated with the BPMS because its semantics for cleaning/clearing out instances is crystal clear. In Anatoly’s model, it's use is essential so that the end of either main thread can effectively nuke the other. The original model also used this element, though for a different purpose - to kill off any ancillary threads spun off by the boundary conditional events. Otherwise, the parallel thread that advances to termination via a terminate request delivered by message flow accounts for the ability to cancel the clam in the original model, which was done through a boundary conditional event attached to the core sub-process though it could also have been done as an interrupting event sub-process. Perhaps Anatoly has had more success in explaining the presence of a parallel thread to capture the semantics of an exception handling moment (over elements natively designed to do that) than I have had, but, as a matter of preference, I would rather avoid doing what he did. This is, though, admittedly a bt of nit.
- The "Evaluate claim" task is now immediately downstream from "Record claim" task and before the "Request info" task, which makes it somewhat different from even the revised narrative, particularly if compared to the original narrative. However, the presumed reason for this is to take advantage of the fact that "evaluation" in the revised narrative can happen after the minimal info has been recorded, which this approach does satisfy (though I'm not sure why the 'Wait for info" option is there as an outcome of the "Evaluate claim" task performance). But, if one imagines what a version of the original narrative would look like using Anatoly’s approach, it would have to be redrawn to reverse the reordering he has done here. Compare that effort, involving several moves and reconnects, to a single endpoint relocation in CMMN.
- Now to the most important point for me: there is a task-driven understanding of how work surfaces that assumes that design approach is used in its implementation - meaning that work is completely work list-driven. In practice, this often means the use of off-book actions, such as stored procs, to effect entry into or exit from what would otherwse be populating queues, allowing instance matching to occur. (Necessary for this as the state is persisted and retired, as opposed to transient and dehydrated.) I'm not a fan of this approach for case-like situations because it severely inhibits an otherwise desirable end-to-end view of what is going on, leading to workers becoming undully comfortable in their isolated view of the flow. (This is no idle speculation on my part. I'm working with a client who presently suffers grievously from this.)
- Finally, even with CMMN vs. BPMN using the Collaboration, once one corrects for the missing event types in Anatoly's model, there will be little difference in complexity of the diagrams, but that is a subjective determination. (Unfortunatley, process models can be like modern art or Rorschack tests - we see in them what we want to see. What is not subjective is that, by any measure I can think of - meta model elements and relationships, serialization interchange schema, # of symbols, page length of the spec, etc. - CMMN is an order of magnitude simpler than BPMN, unless you are working strictly within the Descriptive Conformance Class, which is similar in intent to my simplified CMMN.