To finish out the discussion that started with [url=http://bpm.com/bpm-today/in-the-forum/should-processes-always-be-modeled]modeling and business processes[/url], and an issue that Keith Swenson [url=http://social-biz.org/2015/09/04/no-model-is-a-good-model/#comment-138102]raises here[/url], how important do you think modeling is to case management?
As said in the previous thread, modelling is designing an expectation about reality in order to better
[b]understand[/b]it (via communication) and/or
[b]manage[/b]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
[b]managing[/b]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. ;)
Scott's opinions only. Logo provided for identification purposes only.
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:
[b]communication[/b]tool during the design period
[b]project evaluation [/b](including impact analysis)
input for project
an executable program for the
[b]coordination of work[/b]
[b]documentation[/b]for all staff members
a “single source of truth” for
a framework for
[b]internal control [/b]and
the basis for
[b]management decisions [/b]
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 “
[i]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”. [/i]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 “[url=http://www.expediente-electronico.info]Expedientes[/url]”. 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?
I guess some of your points have been raised in the previous thread - the one about modelling processes.
There's one distinction that I find relevant: implicit vs explicit models. Since we humans operate with abstract concepts (language, ideas, symbols etc), you could say there is an implicit model in everything we do.
A board meeting may touch a lot of subjects in so many various formats, but there may still be an agenda, a list of topics or at least an expectation why people meet (otherwise I would doubt the intelligence of that board). A team of doctors may debate freely about a patient treatment but they would still stick to some protocol and they would still align on some intermediate expected outcomes. An advertising plan may be built on a hunch but it would still require approvals and at least some alignment around feasibility from the team. Detectives would still follow a protocol and some regular reporting requirements while microplanning the evolution of their crime case.
From this perspective - the key question would then be: is it worth making the model explicit? Can we extract benefits from an explicit model that are worthy the cost/effort/time expended?
For me the single most important issue is context and relevance. So, no, I think I cannot model the phases :-).
I reject the idea that the first sentence of the previous paragraph is a model of this response. I think the original question was about a kind of modeling that would be widely recognized as an explicit model of the situation, that was put into a form that is unambiguously a model of the situation.
I also reject the idea that we are discussing "implicit modeling". When I go out for dinner, I expect that I will give an order to a waiter, that the food will be brought, consumed, and at the end I will pay. For this to go smoothly, we need a common understanding of the pattern of interaction for this particular restaurant. It is not, however, necessary for the restaurant or the customer to MODEL this interaction.
While driving the car, in my head I am always projecting forward possible action and predicting possible outcomes: the light it turning red, I could stop which would be safe, I could continue and run the light which would be dangerous, I could pull hard right on the steering wheel and go into the ditch which would be dangerous, etc. Again, I think it is an abuse of the topic to call this kind of mental activity "modeling". As thinkers we are always planning, but this discussion is about explicit modeling of a form that everyone would consider to be modeling.
Now let me respond to your comment. You make some good points. Many of these activities might benefit in some situations from planning. I agree. The key is that they *might* benefit some times, but not all the time. "If it is worth it" These is that cost benefit.
The best example you brought up is the board meeting. Typically it is expensive (of time at least) to bring a group of people together. It can be important to keep everyone on the same topic, and so an agenda is drawn up. I will even agree that an agenda is a model of the meeting in the sense of model we are discussing: it is a plan for what will happen when, and it is used to guide people through the meeting as it is performed. We see here the blurry line between modeling and not modeling. For doctors, I agree that a treatment plan is an explicit model, but my example was not about a treatment plan, but instead a discussion about how to treat. For detectives, I agree that there explicit protocols for much of what they do, but my example was specifically a debriefing. It is not good enough to say that sometimes they use models, therefor they always use models.
So as long as we as discussing explicit models in a form that people agree are models, then I think we end up in agreement: one must do cost/benefit analysis.
Perhaps I have been a bit unclear: in my mind the act of modelling refers exactly to the conscious act of operating with abstractions (even with a physical form) with the consequence of making a model explicit. So while we may have a lot of implicit models, it is not necessary / not worth it that we model them into explicit constructs.
Maybe I should have replaced "modelling" with "designing" to avoid confusion, mostly in my statements.
Sorry if my English sucks.
RE “In summary: who can give me the model of this discussion?” – there are some rules which are defined by Peter, as far as I remember.
- Page :
However, you are not allowed to reply to this post.
Join the Discussion
Also on BPM
- Market Report: Analysis of Process Automation Investments and Total Cost of Ownership (TCO)
- The Three R's of Intelligent Automation
- Intelligent Automation: How Robots And AI Are Redefining The Rules
- Puppy Dogs and AI: Training Automation for Relevance
- The Future of Business is Now: Appian's Malcolm Ross Makes the Case for Intelligent Automation
- The Year Ahead for BPM -- 2019 Predictions from Top Influencers
- Winners Announced in 2018 WfMC Global Awards for Excellence in Business Transformation