As said in the previous thread, modelling is designing an expectation about reality in order to better understand it (via communication) and/or manage it (via execution).
From this standpoint, modelling is a far less prominent need in case management, because there's a lot of design at runtime happening.
Particularly so, while CMMN 1.0 is relatively good at managing the cases, the standard is quite poor at conveying how the case works (i.e. communication). At least I haven't managed to crack it. I still need a lot of comments and additional explanations - which kinds of defeats the goal of clear and concise communication.
Linking back to the comment of Scott in the previous thread, modelling cases becomes interesting when we are talking about discovery of emergent case patterns out of existing case logs and other activity traces and events.
I believe that it's important to model the lifecycle of the case and the information model, partifcularly as they relate to the goals of the case.
The dynamic nature of many cases often make more detailed modeleing a bit fruitless, but these high level guidelines are really necessary for establishing the guardrails within which the caseworker operates.
I'd say: Somewhat important. As I still think you need some sort of context. The whole idea of casemanagement and working with statuses is to anticipate on dynamics and thus increase the flexibility (of the (knowledge)worker).
Now, chunks might be repeatable (e.g. "check credit" process) and those chunks would have been modelled at some point. The challenge is (again): Context. There is a danger you loose overview / insight in the chunks used within the case and I have also seen case-types with so many status-changes that it almost looked like a workflow :-).
So, even if there is no detail, or it isn't automated: Always start with a level 0 (e.g. depicting the phases (not necessarily activities): INTAKE -> VALIDATION -> PROCESSING -> DECIDE -> DELIVER). And, where relevant and appropriate drilldown and create a model, whatever detail.
Modeling is all about level, scope & context. The higher the level and the broader the scope the more valuable building a model is.
If you are trying to understand, improve and automate "Inquiry to resolution" then modeling it (hierarchically and in simple business terms) is very useful. If you are trying automate the "raise new insurance claim and collect evidence" then you can probably go straigh to the case management app or use CMMN
Same answer. The model is the application. If you build a non-executable model, and then build an application that is supposed to implement that model, you'll simply have two things instead of one to negotiate, validate, and update. And of course your implementers will be another step away from the business itself.
That said, you'll certainly need an executable model that gives you the flexibility to build robust applications combining the best of the case management and traditional process approaches. I can help you find one of those if you're looking. ;)
Again as in the previous discussion, the original question can be as the following: how important is explicit planning coordination...?
Advantages of having a formal description of coordination are the following:
All enterprise operational needs should be modelled and Case Management must have high priority. As the Model can now be the build environment using the Declarative technique (BPMN CMMN etc not needed) why would you not enjoy the benefits of fast build direct with users, adaptive capability and transparency for all in what is actually running. This encourages users to think of change knowing they can see how changes might impact on other activity. Such change is inevitable in any Case Management application.
The Case Management we built using the Graphical Process Designer “Model” has in addition to supporting constant change 3 relevant key aspects 75 process maps (226 over life cycle), 2406 associated tasks (5087 over life cycle) and 538 user interfaces (forms) (1114 over life cycle). All joined up and includes key requirements such as selection process, means testing payment scheduling, applying inflation over years and offer and acceptance process.
I have quoted in past thought leader Naomi Bloom “Writing less code to achieve great business applications was my focus in that 1984 article, and it remains so today. Being able to do this is critical if we’re going to realize the full potential of information technology” “….how those models can become applications without any code being written or even generated”. “If I’m right, you’ll want to be on the agile, models-driven, definitional development side of the moat thus created…..” “…”If your Enterprise vendor isn't pretty far down this path, their future isn't very bright”. Naomi goes on to say “It really matters how your vendors build their software, not just what they build” How true….So important buyers understand “how”…
When we talked about modeling an ad-hoc process, some people could think that “there is no model, it is ad-hoc”. Well, let me tell you that it is not that way. There is a model, just this model is ad-hoc, and you have to define several things anyway.
Let’s use an example. The typical “case management” application in our government is called “Expedientes”. An “Expediente” is a case, used for example to encapsulate a citizen request, and all its documents and decisions. So the flow that the “Expediente” follows is unknown until execution time. I mean, once you've created the “Expediente”, at each step users decide the next step.
But, you have to model that behavior, you have to model the offices, roles and persons that will receiving the “Expediente”; you have to set permissions, define deadlines and alerts to be raised, and so on. All these elements are part of the reality that you have to take into account: you have to model that reality.
In sum, even in the most radical ad-hoc case management applications, you have to model. The only thing is that you are modeling different aspects of your business processes.
Of all the people participating in this discussion, who here has modeled this discussion?
Seriously. This discussion is a case. It has a goal, and your goal is to answer the question. Every contribution to the discussion was "work" in the case management sense.
I am betting that not a single participant, when faced with the goal to answer the question, started by modeling what they were going to do. That is beacuse it would be profoundly silly to do so. EIther the model is so trivial as to be meaningless (e.g. clicking the reply button gives me a box to type the reply text into) or it would be far more trouble than simply answering the question.
John: where is your lifecycle model of this discussion?
Walter: I am looking for a model of the phases
Scott: an executable model for answering this question?
Juan: is this discussion too radical to model?
Some of you will surely react saying that this discussion is a non-representative fringe example of a case to be handled, and "real case management" needs modeling. How does this discussion differ materially from a board meeting? How does it differ from a team of doctors getting together to decide the course of action on a challenging patient? How does it differ from a marketing director deciding the advertising plan for the coming year? How does it differ from a general deciding how to attack the next enemy occupied hill? How does it differ from a police detective debriefing a team of field officers who visited the scene of a crime? These are real work situations.
For which cases mentioned in the previous paragraph would a model benefit the participants more than the cost to create the model? That is the real question. You can always make a model, but there is no point in making a model if the cost of making the model is greater than the benefit.
We can always model a discussion as: I say a few words, I listen to a few words, repeat. This kind of model is not useful to the people who are speaking. (It might be useful to a telephone engineer, but that is not business process management.)
Unless I missed it, NONE of the comments on this discussion talked about the cost of making the model. Doesn't anyone else find this odd? There were comments saying you NEED a model, without any cost/benefit analysis.
My position is NOT that a model is NEVER needed. What I am trying to bring to light here, is the UNQUESTIONED assumption that a model is a benefit. We do that far too often. We start with the assumption that a model is needed, and skip right over thinking about the cost of the model. Worse (and this was the subject of the discussion at BPM 2015) we study the model in place of studying the work that people do.
In summary: who can give me the model of this discussion?