1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 02 March 2017
  5.  Subscribe via email
From Karl Walter Keirstead: In a world where Case Managers are focused on meeting Case objectives within a space that is hosting a varying mix of ad hoc interventions and structured steps, how important is it for users to be able to see the evolving unique process for a Case?
Accepted Answer Pending Moderation
Great question @Karl! I suggest that case-oriented workers need context, a.k.a. the "story" or the "narrative". Tacit knowledge informs everything we do, even in the most richly appointed case management system. A BPM process provides that machine-surfaced story or context. With better context informing own personal knowledge, case workers can make the best decisions -- probably significantly better. And likely faster too. Vote "Yes" for process front-and-centre at runtime.
  1. John Morris
  2. 3 years ago
  3. #3444
See @Bogdan's for in-the-field insights in real sales situations concerning what we are talking about.
  1. John Morris
  2. 3 years ago
  3. #3445
Also, "front-and-centre" doesn't necessarily have to mean a full (and overwhelming) BPM diagram -- some subset or simplification would be appropriate.

Yes to "better context informing own personal knowledge" . . . . Cases are great with their Case Histories for decision support (what have we done, what are we doing), background BPM is great for "what should we do next.?"

Hopefully, no Case Manager undertakes to manage a Case without first setting and then having objectives "in their face". Narrative expansions on summary objective statements increase the level of understanding of what we are doing and why.

I have become a fan of ROIs that go beyond narrow financial consolidations relating to specific initiatives to statements on how a particular initiative will contribute to increasing competitive advantage.

If we can encourage people to change the way they prepare/submit ROIs, then parking the executive summary part of an ROI at a Case will help case workers and case managers in their decision making/progress assessments.

For this to work, top management has to get out of the mold where they authorize an initiative and then never re-visit the ROI,

As strategy changes, so should authorized initiatives - if you have an in-progress 'invention" and you discover you have been leapfrogged, you may want to shut down the initiative.

Nowhere do we see how silly things can get but in some governments, where you have, say, a Department of Monuments in charge of monuments that no longer exist.

  1. John Morris
  2. 3 years ago
  3. #3477
@Karl -- clearly narrative as in "narrative expansions" of the objectives of case models are helpful and important. I will go further however, and claim that "narrative" is not merely a helpful tool, but an emergent cognitive artefact of human brains. Here is a blog post I wrote in 2011 on this topic:
The implication is that good software mirrors human narratives. And BPM is probably the best exemplar of software that mirrors narrative. As BPM technology keeps improving, I expect that we will see increasing user/business acceptance of BPM -- because the natural story line of BPM resonates so well with people.
@John. Impressive 2011 blog post on "narrative expansions".

I was particularly interested in "Software works best when it is sympatico with the way that human beings operate"

This reinforces my soapboxing that goes "one size fits none".

I find a sales pitch that tells the customer they will be running THEIR workflows featuring THEIR forms works and that the UI they will be using mirrors the pre-digital "agenda books" they used to carry around, works well.

When the client asks how long? /how much?, the response is . . .providing some homework is done on both sides, . .as fast as your team can respond to ''... and then what do you do?"

Homework includes imaging of all forms for drag and drop on steps, restricting rule building to a narrative of what the actual rules will end up being, restricting each daily session with any one group to one hour of mapping so that before everyone goes away, they will have built, rolled out, piano-played, taken note of most of the logic errors, use of bad forms, bad performance roles and fixed these up with a new compile/ rollout.

When a facilitator hosts a session that resembles a soap opera where you have to wait until the next session to find out what is going on, you waste a lot of time getting back "into" a project.

For this reason, I am OK with a 1-day initial site visit with several different silo stakeholder groups but prefer to then go away and do multiple 1-hour GoToMeetings at a distance.

We see videos as the "narratives expansions " of tomorrow. We replaced user guides with videos quite some time ago,
Clearly, there is more to this than the "initial process" representation.

Converting images of forms to real forms takes 1/2 an hour to several hours per form, depending on the number of data points. If the customer has 200 forms, best to do the math for them.

Rule sets can take from almost no time at all to a "long time" depending on the complexity.

Writing parsers/formatters for data exchange gets to be tedious.

Training time, on the other hand, can be greatly reduced when the users see a familiar UI, hosting their workflows/their forms.
@John, Since it is Friday, may I ask whether future narratives are likely to be limited to 140 characters?

I'm not sure I understand texting. I recall one exchange that went like this . . .

"Where are you?" Answer: At the mall
"What are you doing?" Answer: Nothing... here is a picture of me (presumably at the mall doing nothing)

And, then, from the other side, the exact same thing except "at home"

The chat closed with both parties typing "awesome"

What is it that is awesome in any of the above?
  1. John Morris
  2. 3 years ago
  3. #3502
LOL @Karl -- you're pushing all my hot buttons -- especially that word "awesome", which use to be reserved for things that were, uh, "awesome", like, The Ineffable, for example. As for text, I think it's very interesting, sort of a instantiated version of micro-memes, our most concise thoughts -- and amazingly available to "the masses". Thanks for your kind comment on my original notes on narrative.
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Knowing what is going on for cases is, in my opinion, what BPM is about. It's like a satnav. You set your goal (or make clear the problem to be solved), plan something (as far as possible),

But most important: see progress, see "predictions" and adapt if needed.

So, I vote for important.
Sharing my adventures in Process World via Procesje.nl
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Ever since I've worked with processes, all experts have been saying "hide the process charts, they're too complex, no one understands them, no one cares"

Ever since I've started selling process-driven applications, all customers shout "Aha, that's exactly what I want!" when they see the process charts, populated in real-time with actual tokens.

And now we're exploring original dashboards that actually show processes in a simplified, effective, graphical way - as value flows. I think they're going to be quite popular. But time will tell.
CEO, Co-founder, Profluo
  1. Emiel Kelly
  2. 3 years ago
  3. #3443
Same observations here. Glad I'm not an expert.
I don't think anyone wants to be labeled an "expert". An "ex" is a has-been and a "spurt" is a large drip under pressure.
@Bogdan. . . CPM did/does a good job allowing users to request high level summary flowgraphs.. A process with steps "1-2-3-4-5-6-7-8-9-10" can be viewed as "start - do the work - end" .
Imagine having to oversee 50 construction contracts each with 1,000 steps. Except for the ones that are current, one probably wants to leave the others at the summary level. But we all know that at any time a change at the detail level of one contract may impact many other contracts so it's important to be able to expand/hide on demand..
I was doing FileNet Business Activity Monitor (BAM, Cognos) in 2008. What's old is new.
  1. John Morris
  2. 3 years ago
  3. #3450
BAM is cool. And not always fully appreciated.
RE " "Aha, that's exactly what I want!" when they see the process charts, populated in real-time with actual tokens." - it was valuable since 1995 in ordinary workflow tools. Why all modern BPM-suite tools do not have this feature? Who are those "experts"?
  1. John Morris
  2. 3 years ago
  3. #3455
+1 @Alexander "real-time with actual tokens".
Here's a possible explanation as to why some of today's BPM products might not support such a feature:
Perhaps BPM marketers have learned the marketing "holes versus drills" lesson too well (see the famous aphorism by renowned marketer Theodore Levitt). In too many cases, the holes versus drills marketing lesson has resulted in a loss of interest in real technology, for instance "drill bits". And so today all drill bits are now made offshore (of course there are other reasons for this too). This phenomenon may also show up in some countries as a declining interest in STEM and serious technical engagement.
What happens when you apply this "techno-phobic" marketing approach to BPM? We end up selling "outcomes" and "processes" but don't want to, or can't, get down into the weeds with "process tokens". So our customers end up with a nice "big picture" -- but we are not so much supporting the process worker at the workface. (This is all a bit ironic too -- because a lot of technology is sold with a message of "empowerment" and "democracy".)
I suspect that there's another reason, beyond the question of marketing styles, for the "turn away from technology", which is that deep technology is "too hard" and some marketers and business leaders may have some difficulty in making the leap connecting technical details of BPM and BPM benefits.
This comment is a bit lengthy -- I may be accused of using a sledgehammer on a fly -- but the issue here is important (similar arguments can apply to BAM, referenced above by @Patrick). Insofar as there are modern BPM products (I haven't done an inventory) that don't offer token flow visibility, that's a kind of market failure.
@Bogdan / John What are "tokens"? If they are what I think they are, I am not going to like them.

@John, we could do a few rounds on "loss of interest in real technology"

The Donald may be right on this - the tech jobs go overseas, the factories are dismantled, demand for domestic skilled people goes down, kids no longer register for courses, the mentors/profs move on.

Do this for just one generation then, if, as and when you try re-shoring, the entire infrastructure/channels have to be re-built.

When bother, the kids ask, when you can see yourself as the lead singer in a music band (not all bands today do "music") or as the lead in a blockbuster movie?

On music, I believe it was Itzhak Perlman, when asked what the difference is between classical and current music, responded with ". . . our hits last longer".
@John, maybe people who developed some modern BPM-suite tools never used real processes.
  1. John Morris
  2. 3 years ago
  3. #3466
Hi Karl -- OK, I'll try to answer your rhetorical question! : )
Technically a token is a representation of the place of an actor in a BPM graph (i.e. "we are here at this task"; you can make an argument that a token exists, perhaps implicitly, whether or not the BPM engine explicitly highlights the use of tokens). The engine will use the token (implicitly or explicitly) in calculating available paths etc. An actor action will result in the token moving along the graph.
And the token could be represented graphically to the user in any way that makes sense (sometime represented by a "dot" or "highlighting" etc.)
Do you agree with this explanation? And -- what's not to like?? : )
@Alexamder .. I like "maybe people who developed some modern BPM-suite tools never used real processes". Perhaps we could add to this "... or never developed software suites"
Thanks, John. . . I need to get out more.

We have internal "ids" and with regard to displays at graphic maps, we make available an inventory of distinctive icons that can replace the default square boxes or rounds.

Under the hood, it's all about circles and directional arrows with attributes like name, required skill, imposed time delays, no earlier than start dates etc.

I was worried tokens were some limited amount of run-time info at steps (i.e. performing resource and date/time) as opposed to all posted/recorded data at a step, with data values, as they were, at the time the data was recorded, on the form versions that were in service at the time.

"Logs" simply do not provide sufficient info for Case Management/Analytics.
  1. John Morris
  2. 3 years ago
  3. #3470
+1 @Karl "offshoring"!
I think this could be an interesting question, something about BPM, automation, BPO and offshoring.
Along these lines (social trends and BPM), I note that the most common BPM software demo circa the 2000's was the "loan application flow" -- this continued even after 2008. It was sort of a BPM-as-Rorschach blot on society -- what is the work that we value and want to automate that springs first to mind?
OK, a sale is a sale -- but these demos would be used even for logistics prospects.
  1. Emiel Kelly
  2. 3 years ago
  3. #3479
In the old days, at Pallas Athena, we had a case management tool. For the end user, the process "unfolded" when working at a case. So that "process model" always showed the current state of a case (what's done, what are we currently working on, what might be possible in the future) . It worked for companies that understood goal driven process management and really used processes to help their customers.

Companies with a strict hierarchy and a "you do what I tell you culture" didn't like it. They just wanted traditional workflow. With only YOUR tasks showing up in YOUR worklist. No overview of what is going on for a case.

Oh my god, what is this monster thread of comments :-)
@Emiel. Fascinating but totally consistent with my field experience.

So, the method of feeding tasks to people needs to vary according to corporate culture.

Conclusion: In a corporation where you have silos with different cultures, you have accommodate both classes of user.
@Bogdan.. The "monster thread of comments" seems to be providing a test arena for ideas that various participants have.

e.g. re your Value Flows, I agree these could be quite popular.

The way I would do this is to post FOMM progress assessment snapshots to the run-time Case timeline where everyone gets to see the BPM processes as well as any ad hoc interventions and a notion of value building.

It could be that a single ad hoc intervention causes the Case Objective earned value to increase dramatically.

Drawing the Case timeline, of course, should include actual step durations for completed steps (given that for completed steps we will have this info available).

Looks like we should consider looping back to the early days of CPM where a draftsman would re-draw the entire process map (past, present, future) each week and post 30 foot long blueprints on project office meeting room walls. (e-mapping of course today).

  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
OK. +1, +1, +1 on three responses - no guarantee we will stay at 100% but John and I did a few rounds a couple of days ago on the fact that there are two classes of users.

One is the "in/outtray user" who is singularly focused on transforming incoming to outgoing and has little or no concern about what happens next.

Compare this to the medical example I have given many times over where it is very important to be able to answer a question like "Why did John Doe NOT receive an X-Ray last August?"

Clearly, in the medical example, there was a decision box along the workflow re order/not order the X-Ray and someone in charge made a decision last August based on a Case review to NOT order the X-Ray.

Today, for whatever reason, the Case Manager is looking for reinforcement for that decision OR looking for process improvement so that in respect of future similar cases, the person in charge may find that requesting the X-Ray is likely to be the better decision.

Now, here is the curve ball . . and my reason for asking the question.

If we are to routinely accommodate random mixes of ad hoc interventions (processes of one step each), process fragments (small clusters of steps) plus "end-to-end processes" where we start and when we get to the end we are at an objective, then we need to be able on demand to map out the run-time version of all steps in any Case.

My group lets users view in a Pathway History, all steps (engaged and completed, engaged and current, not yet engaged) plus all steps not engaged, either because the user did a skip or picked a particular sub-path at a decision box resulting in no step along any of the other sub-pathways being engaged.

BUT we don't (and my conclusion here today is we now should), carefully note what the antecedent is for each ad hoc step, each process fragment and each end-to-end process so that we would be able to build a graphic run time Case as if we had started off plan side with an end-to-end process, with no ad hoc insertions and no user, software or robot run-time links.

We already have the wherewithal to this in that each intervention at a Case has in the Case History, the user name, date/timestamp plus any forms where data recording took place, where the user can see data, as it was, at the time it was collected, on the form versions that were in service at the time.

The huge problem (for those who have to deal with forensic cases) is that if at time 18:55 I add an ad hoc step and there were at that time three current steps, which of the three steps prompted me to insert that ad hoc step?

The lesson here is we need to start indicating an anchor point for each ad hoc step, each process fragment you launch at any Case. If there is more than one end-to-end process at the Case, then we need an anchor point for the 2nd, 3rd, etc.

I should probably get my 5 year old granddaughter to help with decision-making at cases - she correctly responded to a question "If you are at a Halloween party and there are three witches, how do you know which witch is which?"
RE "Case Pathway History" - do you plan to have "Case Optimistic Future Pathway", "Case Pessimistic Future Pathway", etc.?

Yes, for pathway engagement but the best we can hope to do is compile stats across Cases and post branching probabilities at decision boxes ( i.e most of the Cases in this category went this way 60% of the time, they went that way 40% of the time).

This will not bring us any closer to hoping to do being able to do ES-EF-LS-LF & Float calcs, even if we were to have assigned durations at steps.

The reason is that most Case workers typically work on multiple Cases and shift back and forth from one Case to other Cases. Their disengage/re-engage "S" curve times can be significant as can idle time between steps.
@Karl, RE "Case workers typically work on multiple Cases and shift back and forth from one Case to other Cases" what is the typical frequency per hour for such shifts? Sure that is not 30 times per hour as at the reception desk. 2 time per hour? What is the frequency of returning cases?

To reduce this idle or warming-up time, we used automated pre- and -post- activities around each human activity AHA pattern). Those automated activities do any "mechanical" work like a good secretary.
@Alexander . .. difficult question . . .

In healthcare, aside from reception desk which we don't need to bother with, Intake is likely to process 30 cases per day. Not uncommon to get part way through only to find that a key piece of data is missing, so the Case has to be suspended and later resumed.

A law enforcement investigator, on the other hand, aside from answering calls/questions relating to other open Cases, is likely to be working on one and only one case that has just opened up.

Insurance claim processing? Maybe 100 open claims on any work day with various pieces of information flowing in at random times.

IT Service Tickets? One customer we work with has a Tech Guy who manages 100 separate applications. I suspect his hot line phone is off the hook for most of any working day.

RE "Insurance claim processing? " in Switzerland, it is rather formalised activity as we have so called, TARMED, country-wide standard for for medical services. The claim processing is an application with about 1000+ rules which helps an operator to take a decision in difficult cases.

RE "IT Service Tickets? " again, a group of helpdesk people (level 2 and level 3) treats cases one by one. Of course, level 1 has many different cases per da, but , practically, all of them are different ones.
@Alexander .. No surprise to hear things are well organized in Switzerland.

My best example of multi-tasking at Cases is the 100 application Tech Guy, He takes care of 1st line support but occasionally gets calls that he needs to refer to us where we have to log in and shadow a user to find out what it was they were doing when some curious event took place.

For systems that have been in use for 10 years where the software has gone through many upgrades, even with constant attention to backward compatibility, we discover data clashes from time to time that take hours, sometimes a couple of days to sort out.

In the normal course of events, the logical expectation is the software should be able to handle any incident but in our case each customer install is different. We often discover customers using the software in ways we never thought of.

Not uncommon to have 5 open tickets with this customer with new info coming in that requires re-visiting a ticket several times.

  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
There's definitely an appetite for where is this thing going after I submit it? and related questions. Employee and customer engagement demands some amount of visibility and expectation setting. (On a related note: that includes the question, when is this thing going to finish?, one which is awfully hard to answer in BPMN-style processes as well as case management applications.)

That said, one of the great benefits of a BPM engine is the ability to determine routing, task assignments, etc., on a just-in-time basis. If I'm relying on that capability—and, as far as I can tell, virtually all of my customers are—then the information I can provide about the future may be limited. That uncertainty creates space for some interesting innovation, such as predictive analyses, etc.
Scott's opinions only. Logo provided for identification purposes only.
A rules engine can do the "where is this thing going after I submit it?" based on criteria you define. Where it goes next can also be determined by the user, including ad hoc. Or both can be done. The trick, hard, fun part is, when capturing where it went next and WHY (in the event of human routing), can we take those captured heuristics and extrapolate with any degree of precision. Yeah, the smarter predictive analytics gets, the funner this will become. Meantime, it's only as good as we tell it to be.
Right, this is why we have Case Managers managing Cases.

I agree with Scott that JIT scheduling is something that BPM / RALB do very well.

When a step along a pathway becomes current, it automatically gets broadcast to all users (machines) that have the requisite skills and availability. The first to "take" the task owns it and the task clears from the InTrays of all of the other users.

A good way to explain this to customers is to give the example of a corporate front desk where you might have four attendants and the phone rings.

JIT is very complicated in medicine where there is an expectation that if you "take" a step, you are expected to complete it or make a formal put-back of the step to the resource pool or make a handoff to an identified person.

If a nurse takes" a step, starts an intervention and then simply goes off shift, that step is absolutely blocked from access (other than view access) unless the nurse does a put-back or handoff.

Anyone wanting to advance/complete the step has to invoke a protocol called 'Break Glass" (probably named after the fire extinguisher/axe boxes we used to see on trains).

BG requires that a new attending makes voice contact, finds out whether the person who went off-shift performed or did not perform the intervention or, in the absence of being able to make content, makes a "best practice" decision.

Part of gaining access is to document in a note why the Case step was accessed. Both parties then have to go on the carpet and explain. Hospitals don't like it when they see BG incidents.

@Scott, we're doing that currently via success messages directly in the portal, who reads instance variables and says back to user: "Because you did X and Y, your request is on its way to Mr. Z". Works as an online contextual training tool, too :-)
@Patrick raises an interesting comment here above "A rules engine can do the "where is this thing going after I submit it?" based on criteria you define."

All of the rules I seem to be working with only fire when steps become current but I can see no reason why not-yet-current steps along a pathway could not be tested as a means of anticipating problems downstream from current steps, bearing in mind that if the data pickup lies between current steps and forward steps being tested, the "problems" may never materialize.

It would be complicated to do test firing taking into consideration data that should have been collected upstream from current steps but was not collected and where none of the forms at current steps or downstream up to the test step(s) feature forms that can pick up data initially missed.

We must not forget either that some of the data needed at steps that feature rule sets (pre-conditions, rules at steps, post-conditions) can come from outside systems and apps. Here, the Case environment may not have much in-place logic to fetch data, the Case just takes in whatever data happens to arrive and, only once in, can the data be accessed by any rule set.

Anyway, it could be possible to get answers to "where is this thing going after I submit it?" by test-firing forward branching decision-boxes. e.g. we have a complex flowgraph for a homicide investigation and if an early determination of gender is possible, then for any dynamic re-drawing of process maps, if we know that the victim is a male, we could, as part of any re-draw, eliminate sub-paths dealing with issues that relate only to female gender.

Would all of this be worth it? a big yes, in my view, because homicide investigations are complex connect-the-dots exercises and any elimination of clutter is likely to be appreciated by investigators.

I don't think we should call such filtering "AI" - it really is nothing more than filtering.

@Patrick's comment above is not simply "interesting" . . . - it is absolutely brilliant (i.e. forward testing of rules - "where is this thing going after I submit it?")

So, after consideration, I am on board with real-time updating of run-time Case process maps, with suppression of sub-paths we know will not be traversed.

This could result in a re-draw of space-consuming downstream branching decision boxes as ordinary workflow steps where the such boxes have only two (2) options and we are able to eliminate one of the options.
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
Continue Scott's reply by adding another popular question from line-managers "Are we still in SLA with this process (instance)"? And how we tried to solved it. http://improving-bpm-systems.blogspot.ch/2010/03/linkedin-how-do-we-measure-work-flow.html

LOLOLOL. Laughed so hard on that one I'm choking. I know that guy. ;)
@Alexander ... I love the "spring" representation.

Very easy to set a project milestone in CPM because everything converges to 'cut the ribbon".

With BPM, on the other hand, we mostly have 'process fragment' instances and this includes ad hoc process fragment instances of one step each. Few case managers bother to dovetail all of these to one end node but, that node, whether real or virtual, is where you find your SLA.

Given the difficulty of responding to "How long will it take you to invent this new product?" plus the fact that a) in the area of managing Cases people work on many Cases plus b) Cases often sit idle for a few hours/days, it's not so easy to answer "Are we still in SLA with this Case"?

The best I have been able to do is include a start->end process at a Case, with a counter at the end node that shows the number of days remaining.

This allows the Case Manager to overview the Case and conclude such primitives as "This Case has 20 remaining steps and 3 days to alarm time whereas that Case has 5 steps remaining and 20 days to alarm time". It may be the Case in danger is the one with 5 steps.

Over the six years I spent on "predictability of time" on major construction projects, our team got to where we could predict end node arrival times.

If, during the 1st 20%, a project starting up with a float of +4, picked up negative float and we reported the trend, management would scream and the project managers would immediately compress the timings of your "spring" step 3 AND steps 4-5-6-7-.... The resource demands would peak but the project managers would say, no problem. They did not worry as much about the cost projections as these took longer to revise/update so most of the screaming had a focus on time management with the implication that time delays would cause costs to increase (sometimes exponentially)

The outcome was that any float boost would erode and the project would end up exactly where our curve projections showed prior to the time of the compressions.

Another thing we learned was there is no such thing as "a critical path" - if you see -8 weeks and allocate more resources along that pathway you cannot simply focus on the -8 path alone and get to +4. It depends on what lies beneath the surface.

A project with 3 merging pathways reading -8, 0, +8 may be capable of going to +4, whereas one with -8, -6, -4 will take a lot more effort to get to +4
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
Delivery of operational front line processes needs the digital form for users to interact and the orchestration of required data from or to any source as required. This ensures the adaptive capability for the UI and simplifies support for change. Who did what when should be transparent for those authorised to access such information. With users now able to be directly involved in the build there should be an understanding of how all work tasks blend into the final all outcome. Being "front and centre" as described will encourage users to be aware of opportunities to suggest better ways to deliver the outcomes?
@David... Thanks, I had not thought about the link between being able at run time to see "how all work tasks blend into the final all outcome", thereby suggesting "better ways to deliver the outcomes"

This brings up another useful change/addition to the UI - for some users who may be new to performing a particular step along any pathway, it can be a good idea to post, as the 1st form at a step, an "instruction" paragraph/image and ask the user to click to confirm that they have "read and understood",

This accomplishes two things
a) a reduction in time delays caused by users having to call someone for instructions
b) reduced errors that typically would result from not performing the action the right way.

A refinement might be an "expert" login option where a user would not see the instructional forms.

We had had trouble over time with inattentive users clicking Yes, Yes, Yes at various prompts. This has led to "Do you want to Delete?" followed by "Are you sure you want to Keep?.

Best these constructs get used vary sparingly because too much fancy/tricky prompting and you get a palace coup.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
Re the reference above to "complex [at run time] flowgraph for a homicide investigation".

This seems to provide a good example of Case Management where there is a combination of a need at times for very strict adherence to protocol (e.g. evidence chains of control) mixed with ad hoc steps where even lead investigators are unable to explain how one step is linked to another (i.e. random leads that the general public calls in).

Homicide investigations are even more interesting in that there are connect-the-dots opportunities across Cases (i.e the MO for a suspect involved in one case is about the same for another Case involving a different subject and the investigators discover as the two investigations move forward that both subjects were in the same jail cell 10 years ago).

I don't think data mining would help here because unless/until an investigator looks up incarceration records for both suspects (in separate Cases) there would be no data to mine.

Why mention all of this?

It reinforces, for me, the need to augment traditional Case Management w/ core BPM to cross-case connect-the-dots initiatives in a free-form-search KnowledgeBase.

It expands options where a Case worker could seamlessly switch between a multi-Case (hierarchical) Kbase and a traditional single-focus (rdbms) Case Management relational database.
  1. http://www.kwkeirstead.wordpress.com
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Good question. I am a bit late to the discussion, but here just to chime in: showing the model is EXACTLY what customers want, so long as the model describes what the people are doing. To participate in a process, you MUST have a mental model of that process. Any visualization that supports the formation of that mental model is great.

I think BPMN model most of the time are helpful in that. It is certainly possible to use BPMN and make a model that is no help to understanding, but that is not the majority of cases.

"The lesson here is we need to start indicating an anchor point for each ad hoc step, each process fragment you launch at any Case. "

I think you are on to something really big here. I just got word that we will be holding the sixth Adaptive Case Management Workshop in Quebec City in October of 2017. Maybe that is a discussion for that meeting.

  1. https://social-biz.org/2008/01/01/human-process-trouble-ticket/
@Keith, great news re Quebec/October. I will definitely attend this event.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
  • Page :
  • 1

There are no replies made for this post yet.
However, you are not allowed to reply to this post.