1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 25 May 2017
  5.  Subscribe via email
From Karl Walter Keirstead: As managing cases is such a crucial aspect of BPM, how do you define and set-up cases?
Accepted Answer Pending Moderation
With a Case I generally start with identifying all of the Activities that can be performed (with no thought of order), then determine dependencies if any.
With a Process I generally start with the Flow, identifying Activities sequentially as the transformation progresses.
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions

Works for me . . .

I suspect it helps to have on hand an inventory of various processes that you can load into your Case and, as you indicate, later worry about dependencies.

Your point about "starting with the Flow" (i.e. what is it we can do right now, easily, that advances the Case?) is good advice.

Being able to "Identifying Activities sequentially as the transformation progresses" is essential - nice to have "stock" processes but very important to be able to insert ad hoc Activities, on demand, without having to go through the formality of mapping out a new process of one step, compiling it, and only then being able to engage processing of that new process.For this reason, we always include in our inventory of procresses a "none-of-the-above" process of one step that has nothing on the attached data collection form but a memo field.
case is trees, process is forest?
What Dr. S said.
@Alexamder - I think I understand your trees/forest analogy.

The land, presumably, is the corporate asset, the management has picked an initiative ("how do we put the land to good use?) called "build a forest" (as opposed to planting, say, wheat), and the customer deliverables are trees.

The process inventory reasonably becomes the know-how and protocol for protecting the forest and growing the trees.

There is only one Case needed, if all of the trees are of the same type, but, if you have a cluster of apple trees and another cluster of spruce trees, then you need two Cases because the way you nurture and grow the trees and the harvesting are quite different per cluster.

Seems to work fine.
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
I look at the business problem and take the business objects/artifacts that need to be managed and start my concept of case there. It is a very data- and context- driven viewpoint, but context is exactly what a case is when you look under the hood.
Indeed, Case journies are context and situationally specific. In theory, no two are the same.

Case outcomes can be dramatically improved by orchestration from background BPM (follow the best practice where appropriate, but skip, jump, steps and insert ad hoc interventions where deemed necessary) and by governance in the form of rule sets at the Case level.

The reason it works (i.e. follow the practice/don't follow the practice) is corporations hire people who know what to do, how to do it, when, and why, and they can count on them to not frivolously not follow best practices unless there are valid reasons for deviating away from best practices. As and when they do, governance reins in extreme, unwanted deviations.

You can have to people sitting side by side, one following the best practice(s), the other not following any "best" practice - they will typically reach the same outcome, one the easy way, the other a more difficult way.
Sure, in theory, they will reach the same outcome but we all know that . . . .

"In theory, theory and practice are the same, but, i n practice, they are not"
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
So, 2/2 it seems, for "case" being a "bucket" - you identify what you can do (John), what you need to do (Rachel), you load BPM process templates into the case and the route to meeting case-level objectives you have defined is very much data and context-driven.

Clearly, just as I can have "process templates", I can have "case templates" (i.e. this set of process fragments, linked this way, worked last time, so why re-invent the wheel especially when I have the flexibility at a case of being able to skip steps, re-visit already committed steps, record data at steps not yet current along the case timeline and insert ad hoc steps at any point along the timeline?).
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
Fore me the "case" is single execution of the process. Its is like a "project".... specific customer, activities, people, defined time etc.... A "case" could be a plan to execute or something what really happened in past.

I use cases when designing the process. This is for me kind of reality check.

br. Kai
OK, Cases have objectives, so they are indeed like projects. And in a world of process "fragments" there really is no "process" until the Case Manager closes a Case (i.e we don't know the entirety of the process until the last step has been performed).

And, since we like/need to have Cases sit around for future reference, " a 'case' could be a plan to execute or something what really happened in past"

You say you use cases when designing the process - that sounds like modeling where the objective is to validate/improve. - again, this works for me.

My observation is we build processes, model them for a short time, then we stream items of interest (patients, customers, critical incident events) onto process templates thousands of times so the greatest benefit of process is to make it easy for users to make consistent use of processes because we know what consistent use (with the ability to deviate) leads to better outcomes.
Seems to me there are two ways to ". . . use cases when designing the process".

One is to mine the run-time data across cases of the same type and observe statistically that at, say, step three, users almost always insert a step between step three and step four.

Another is to ask the users as and when they make insertions, what the anchor is for the insertion (i.e."I need this to be done after I commit step three but before I engage step four" - this puts you in a position where you can draw a run-time map for the Case (original process templates, updated for skips, jumps, insertions).

Not too much of a stretch from here to build composites where you show what happens 70% of the time, 80% of the time and 90% of the time.

A process designer might not want to update a process on the basis of case pathways that are observed 70% of the time as this would lead to more user skips, but the designer might feel it worthwhile to update a process for pathways that are observed 90% of the time.

And, no real obligation to update a process at all if the designer posts hints at branching decision box options (e.g. most of the time they went that way, some went this way, only a few went this other way).

I find attempts to make workflows too "smart" ofter backfire as users stay up nights wondering why the software is suggesting they do this instead of that.
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Hi, we are five hours into this Question and only 3 responses (aside from one I made).

How about I try to get people to rise up and shoot down the notion that you need Cases to practice BPM where a Case has traditionally been either an index position in an RDBMS OR perhaps just a "folder" you can get to by clicking on Microsoft's "File Explorer" (or equivalent).

The thing is we recently discovered that a hierarchical DBMS works better for law enforcement investigations because ideas for what next-to-do to advance a particular Case often come from other Cases so investigators like to see all of their Cases at one screen (as nodes in a free-form search Kbase) instead of having to open/close individual Cases.

The apparent best configuration for law enforcement investigations becomes nodes on a free-form canvas, each representing a Case, with a virtual link to a Case record in an RDBMS.
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
I think I'm most with Kai.

To me a case is "the problem to be solved for the process customer" or "the thing that flows through the process"

That can be very concrete "emiel is hungry and orders a pizza" or less clear like "Emiel has been suffering from headaches for 2 months now"

In the first situation the process can be more standardized for each case. In the second situation the case might be leading in what are the best next steps for that case.

That is also the reason why I often visualize cases as balls flowing through a workflow.

Like I wrote here http://procesje.blogspot.nl/2016/05/does-new-gold-work-for-your-processes.html?m=1

To me cases are just what you execute a process for. And that process can be of many types. I never understood all the discussion about BPM vs Workflow vs Case management. Like I wrote here. To me it's all case management. By process.
  1. http://procesje.blogspot.nl/2016/05/does-new-gold-work-for-your-processes.html?m=1
Sharing my adventures in Process World via Procesje.nl
Hi, Emiel

All of the points in your article work

Re ". . .make a distinction, like the cycles, between data on different levels to manage your cases and processes"

1. Data needed to execute the process for one case - true because with data missing, rules will not let you advance through the process. And, if you have branching decision points where you happen to have a state of affairs that maps to NONE of the branching options (and you have not made provision in your rule set for "nothing or absent"), the process fails.

2. Data needed to manage all the cases currently in the process - important and best example of this might be a global (i.e. across cases) floating data item called "we have available cash" that tells a case whether it is ok to proceed.

3. Data needed to improve the process(design) - again, yes, because with the accumulation of data relating to many executed instances of a process at many cases, you can, for example, discover the time to mail a package from a factory to different countries and automatically insert a transit time between ship and receive.

4. Data as a link between different processes - sure, and an example here might be incoming message "fire alarm has gone off" (a piece of data) that launches a) call the fire department b) call the companies renting space in the building d) call the owner of the building.
The notion of "balls flowing through a workflow" might have as an example a custom snowmobile moving along a production line. (the case flows through the process).

Servicing a Blackhawk helicopter, on the other hand, sees the unit staying put, with people, tools and parts going plane-side every day (the process comes to the case)
  1. Emiel Kelly
  2. 3 years ago
  3. #3991
All makes sense of course. But in your black hawk example the problem "blackhawk needs service" is still the case flowing along activities to be done.

With my balls visualization I don't want to express where a case physically is, but what's the status of it in the process.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
Good question @Karl. Consider that case concerns the intersection of work, process and "the tacit". (I notice that the idea of "work" as such, has not been mentioned so far.)

Interestingly there was a good discussion on this topic a year ago on BPM.com (March 29, 2016).

I noted (with tip-of-the-hat to @Patrick Lujan) the difference between ante-to-play BPM functionality and important ad hoc-capability-that's-easy to use. The difference explained 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. And that lack of knowledge makes constructing a worthwhile business process challenging.

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" . . . ) (NOTE: E. @Scott Menter pointed out last year that the "S" in STP doesn't stand for "static" . . . and that many so-called STP processes can be very flexible.)

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. Especially the elephant in the room is "the tacit", always the tug-of-war about the tacit.
@John. we talk about steps, tasks, and work.

One way to cope with the terminology is to say that processes have steps, the steps post to the attention of workers and become tasks. Workers take note of these tasks (things-to-do), go away, perform "work" and then come back to the Case to attest to completion of such work and, if appropriate, record data, attach an updated contract they edited, etc.

Along a production line, the usual scenario is there is a workstation and the work takes place at a particular physical location.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
Case is a time-bound attempt to achieve a particular goal

time-bound = a case is “opened” and “closed” over a period of time (let us presume that Emiel is hungry now although he may be always hungry)
attempt = there is no fixed and predefined algorithm to follow at various circumstances thus case course-of-action must be adapted over the time depending on a concrete situation (today is a pizza day)
to achieve = to direct case participants’ activities (to order)
goal = desirable end-result, for example, a court hearing was won, a patient was rehabilitated, customer’s problem has been resolved (Emiel will let us know the result of that pizza)

Case management is a set of practices for the coordination of case activities also known as “Dynamic case management” and “Advanced case management”.
Many different coordination techniques are available.

"Time-bound attempt to achieve a particular goal" . . . . works for me.

The main objective of most cases is indeed to close them (i.e. we are done).

I think it's important to stress that Case Management takes place AT individual Cases (we focus on the goal of each Case) BUT we need to immediately qualify this by saying that "work" typically occurs ACROSS Cases (e.g. a nurse attends to many patients on any given day; an insurance adjuster works on many claims), so, the runtime environments we use for ACM (that host BPM process templates and accommodate ad hoc interventions at Cases) need something like 3-tier scheduling.

e.g. background BPM and incoming event transactions relating to patients/insurance claims/law enforcement investigations cause steps to post, users themselves post steps, users then micro-schedule their tasks for the day, and supervisors level and balance workload across users.

It's not practical to park Cases in individual file folders and expect to build a "current tasks" list that covers 20-30 Cases.

The run time environment is the place "where" users actually record data relating to steps. Committing a step in what amounts to a to-do list line item is what causes the data for the step to go to the Case.
As you have pointed out many times, the architecture is important.

Having nothing more than a to-do list for case steps immediately causes "Case" to fail unless the user has easy access to the case history.

One of the most important attributes of "Case" is to be able to present a chronological history of all interventions - many of the decisions that users make at steps can benefit from a quick consultation of the Case history (i.e. did we ever do this?, who did it?, when?, what was the result?)

RE '"work" typically occurs ACROSS Cases ' - not only on the scheduling perspective. Good things found in one case may be propagated to another case (quality perspective). Also, one case for a particular "final beneficiary" may affect next cases for a returning “final beneficiary” (life cycle perspective).

Considering that case management does not cover “customer journey”, the latter may be considered as yet another branch of BPM. Just kidding.
Excellent point regarding propagation.

We had a 100-year flood where I live.

Rather than accumulate data across claims, then mine the data and then upgrade processes, it is much more productive to identify a few model Cases (i.e. damage to basements, damage to cars) and clone these for other Cases, effecting minor changes as necessary at each cloned Case. Chances are the insurance company will not see a repeat for another 100 years (except that we know because of global warming that 100-year floods may end up being 2-year floods).

Nothing new here when we compare the approach with the way things work with O-O programming languages where inheritance/re-use and feature-overriding yield tremendous savings
@Karl RE "inheritance/re-use and feature-overriding yield tremendous savings" - and added a lot of complexity in IT solutions.
@Alexander - we mostly use O-O but I cannot say whether our IT solutions have/do not have a "lot of complexity".
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
From a broader point of view, one also could define a case as the process object, while the workflow describes the logical sequence of possible process steps.
So, for example, a case in a mortgage process could be the request whose desired outcome entails a decision (approval/rejection). In that sense the case definition would be multifaceted, covering possible logical pathways, activities, expected response times and so on. As well as an ad-hoc element that caters to the "A" side of "CM".
There are great examples here: https://goo.gl/TuaX1T (at BPM-Books.com).
NSI Soluciones - ABPMP PTY
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
"Any collection of activities that lead towards the accomplishment of a common business objective"

--Oh wait, did I just copy and paste my definition of a Process? :-)
CEO, Co-founder, Profluo
Just two different viewpoints on the coordination of work.
Good definition. . ."Any collection of activities that lead towards the accomplishment of a common business objective"

In ACM environments, we all seem to recognize that you typically don't have a "process" until the Case Manager closes the Case (i.e. it's impossible to predict what the last ad hoc or process fragment launch will be)
my point, as correctly noted by Alexander, is that the only difference between Process and Case is the degree of coordination (strong vs lax).
if you approach both with the same mindset, you realize the difference is negligible in front of the customer.
of course, vendors will claim customers will need different engines and architectures.
they don't.
Thanks, Bogdan . . .

I can readily see that a Case could have as it's objective the evolution or ongoing maintenance of a process. Under this scenario the Case is the repository for the process map.

In the normal course of a workday where users are running instances of compiled process maps (templates), things start to diverge, IMO, as users manage their personal workload across all of the cases they are parties to (what pending/current steps across 20-30 Cases do they address, say, this morning?; what steps do they then address?, with supervisors in the background at times offloading Case steps to others).

Here, customers do need a set of capabilities that include BPMs, RALB, FOMM and Data Exchange, otherwise, I maintain they are not doing "Case Management"

With the increasing influence of IoT, I think it no longer matters what engines are in/not in a Case Management environment. Take CPM ES-EF-LS-LF calculations for example - if your run time environment does not have an embedded CPM engine, simply export your nodes/arcs to a CPM environment where you record durations, have the CPM environment find the critical path, then export/import back to your BPMs and you are now able to highliight the critical path. Most Case Managers see this as a waste of time for other than end-to-end processes because it is impossible in advance to anticipate all manner of skips, jumps, insertions.

The only way I have in my software to impress upon users the urgency of reaching goals is to put a countdown alarm at goal nodes. The problem here is you can have two pathways both with next Friday as a goal where one pathway has 17 remaining steps of unknown duration and the other has only 3 remaining steps of unknown duration. The logical reasoning says the priority needs to be on the pathway with 17 steps.

  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
Case is the focus on the delivery of a product/service to people/organisations. HRM it is the employee, CRM the customer, SCM the business linked to suppliers, Healthcare the patient, Government the public....... the point is the focus is quite specific from which many different process and likely established processing (e.g. wage and payment processing) will combine to deliver the required outcome. This requires data structure to have such a focus before build begins assembling required pre coded business logic.

It is inevitable in these case environments need for change is inevitable to remain competitive and support improved productivity. Hence the Adaptive tag was created. The approach very much outside in thinking where BPM can bring structure to help engagement with all user needs.
"... will combine to deliver the required outcome" - it seems that a case is a group of coordinated processes.
@Alexander... " a case is a group of coordinated processes" for sure

No distortion of this statement is needed if you declare ad hoc interventions to be 'processes of one step each" - everything in a Case becomes "steps along a process".

The only qualifier is that cases are made up of process steps plus attachments (documents, images, video/audio ) that users append.
@Karl, "processes of one step each" - I also accept that any step may be a process as well.
It's a minor thing really, but extremely convenient to avoid having to consider an ad hoc intervention of one step as 'special'.

In our work we present to the users a "menu of services" that is trimmed according to their rights/roles. They click to stream (in healthcare) a patient onto a pathway and the beauty of this is it can be an end-to-end process or a process fragment or a process of one step.

All the same!, just check the checkbox and away it goes.

A must - have for this to work is ONE process of one step where the attached form has nothing on it except one memo field (write what you like, then go away and perform work, then come back and commit) and the processing moves along.

We need one rule that says if the patient has completed the last step on the last workflow then we want the rule to post the menu and ask "what next?" or "discharge?".
@David ".. This requires data structure to have such a focus before .."

Yes, indeed, because I can easily have an app that needs simultaneous Case Management for Customers and Suppliers - clearly the data elements are different so you need two RDBMS .(Customer and Supplier).

Some Supplier Case activity needs to be mirrored to a Customer Case (special order) whereas an order on a Supplier to replenish inventory is not likely to be of interest to Customers.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
Case is a grouping container intended to hold artifacts and operations associated with certain business entity.

Business practice normally deals with complex mutable structures, which have no clear and stable equivalents among classical data primitives. Case is convenient generalization to express this inherent volatility while preserving the unifying business idea behind this ad-hoc association.

Case offers convenient and flexible view on a set information entries and their associated rules of manipulation from different angles of distinct stakeholders and user groups according to their business roles.

Technically, case serves as a bridge between transactional world of relational databases and tree-like document oriented structures of object storages. Case conveniently unites SQL, NoSQL data and procedures (processes) under an umbrella of business logic. Case can be considered as a View Model within a popular MVVC paradigm.
Re: "case serves as a bridge" - good point.

We use hierarchical DMBS' for corporate Kbase-building (asset inventory ->possible initiatives -> initiatives to be implemented).

Since resources are often tentatively assigned to initiatives and are reallocated as initiative priorities change, it is convenient to be able to park a virtual instance of a resource under each initiative that draws on that resource.

At the Operations level, Cases are then set up (one per initiative or several sub-Cases to one initiative).

In most customer environments, all work is recorded/ tracked at the Case but recently, in a law enforcement connect-the-dots setting, we found that investigators have a frequent need when looking at one case, to refer to data in other cases.

What they need is an easy/transparent way to browse free-form data across several cases (e.g. suspect in a robbery has an associate who is a suspect in another robbery - it becomes useful to be able to look up events in both cases to see whether the two suspects have been working together).

Here, we find the investigators accessing individual Case data at the Kbase, or at the RDBMS Case record, perhaps inputting data at both and the obvious remedy/solution was to synch the Kbase with Case records. (e..g data recorded at a Case goes "up" to the Kbase; data recorded at the Kbase goes "down" to the RDBMS Case record.).
@Karl, very interesting approach. We roughly follow the same schema on our Enterprise Explorer Portal. We support visual case management with Visio where users can visually depict operations, objects and relations within a case diagram and insert into it links directing to actual documents on a cloud storage. In this way users can create unlimited number of projections / views for a single document tree of artifacts.
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
I like Bogdan's "Any collection of activities that lead towards the accomplishment of a common business objective."

Cases indeed have a singular focus - that of opening them and then closing them.

Without an objective at the case level, any decision to close can become arbitrary.

Since most case run-time environments support "attachments", why not attach a "list" of Case objectives that is one-click away from any open Case?

We can move further away from arbitrariness by recognizing that most cases have multiple objectives - some of these are more important than others - you typically don't have to attain all of these objectives in order to close any case.

Of course, there will always be a need for abrupt case closings (e.g. you are building a "next generation" whatever and discover you have been leapfrogged; the patient died during surgery, there will be no need for post-operative at the clinic follow up visits).

Absent better suggestions, I stick with the Rand Corp's FOMM (Figure of Merit Matrices) for guidance re when to close a Case.

I believe The Rand Corp invented FOMM but they don't today seem to know this (I asked them to do a search of their archives back to mid 1960) - and I am unable, to any reasonable extent, to independently confirm this either without driving 200 miles to pick up a thesis I wrote decades ago focusing on FOMM.

FOMM is super-easy to implement.

You can click to view an article I wrote on FOMM in 2012.


And, for a wrap-up on essential services at Cases, see the following

"A framework for development of a Case Management Maturity Model"
  1. http://www.kwkeirstead.wordpress.com
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation
We might as well take a quick look at "data interchange" in and out of Cases.

The starting position is "no case is an island" and with IoT, an increasing amount of the data needed at a case to make decisions, advance the state of the case, etc. is going to come from the outside world.

Case Management will start to look like automated industrial control systems of the 1950's, in some industry areas, even before this.

Question: How do you get data to flow into Cases? How do you export data out of Cases?

The answer is to use a generic data exchanger so that your Case can take in data from ANY source, pretty much in any format (you may have to write a few parsers/formatters until contributors/subscribers get fed up and figure out that it is easier to use an existing format rather than invent a new one).

Secondly, you need along your processes, PCPs (Process Control Points) that hold up processing, waiting for remote batch uploads to your data exchanger, waiting for data input at portals from at-arms-length "users" who are not allowed to establish a cursor position at your Cases). The cycle times can be set appropriately (every 30 seconds for things the Case urgently needs, 1 hour for other data, possibly once a week for a contributor who only outputs data once a week).

The IT choices at the data exchanger are "push" or "pull" and in any app that has a sizeable number of contributors (some industries/apps have thousands), I prefer "pull" for reads.

I believe Costco uses this approach - you want Costco to sell your goods? Deliver them yourself on a pallet right to the storage location with most, I suspect, of all of the needed labeling. (Does anyone have details on the Costco receiving system?). Most of the heavy lifting (no pun intended) is done by the suppliers.

As for outputs, with "pull" you just post data to the data exchanger and the subscribers do the rest.

None of the trading partners need to worry about naming conventions - each reads and writes using their own internal data element naming conventions and the data exchanger not only does the crosswalk but the setup very conveniently takes care of one important security (need-to-know) issue. No crosswalk name -> do data sharing so prospective subscribers need to go cap-in-hand and tell the publisher what data elements they want/need and provide the crosswalk info. At run-time the subscriber readers skip over any published data elements that lack the crosswalks. This means the publisher can publish ALL of its data and the distribution is managed by the data exchanger.
I m not exactly sure, if case, as a grouping or view, should mandatory relate to data exchange. It might be much more flexible to store in case the links to data records instead of the actual data. In this situation, data exchange looses sense because data reside externally and symbolic case links just refresh on data updates.
Less storage, yes, but not more flexible if I have Cases on a laptop and I am out of the office where there is no internet connection.

Failure to record data AT Cases (all of the data) would be disastrous in healthcare where, to illustrate, I go to the history at some point, make a life-death decision based on what I see in the history. . . . and then later, I or someone else, returns to the history and does not see the decision data that I used (i.e.the source link broke or the source author changed the data I used to make my decision).

Rule 1 with any official repository is that once in, no changes are allowed.

Storage is cheap today for everything except images.

Clearly, real histories need to go beyond audit trails that only document that someone did something at some point in time. In healthcare if you are monitoring say blood pressure, you need to post to history all of the readings - if you do 3 measures a day over 90 days, you have 270 BP readings in the HX, each with a date/timestamp and a user "signature".
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Accepted Answer Pending Moderation
Almost done here!

My takeaway is there is a general consensus re what Case is/means. I did not anticipate this.

It has always been my view that Case and BPM are intertwined, to the point where I am not able to see how anyone can practice BPM in the absence of a run-time environment that accommodates:

1). Auto resource allocation, leveling, and balancing (RALB).
2). Ad-hoc insertions (skips, jumps, variations away from structured sequences of tasks/steps).
3). Data exchange (in/out from IoT/to IoT).
4). A non-subjective means of assessing progress toward meeting Case objectives (FOMM)

Looking back at a paper I wrote in December (2016 Recap - Basic Requirements for Success with BPM) detailing 11 steps for success with BPM, what leaps off the page is that 7 out of the 11 points refer to "Case" capabilities.


Now, for the bad news - my point #11 reads . . . . . ( click or you won't see how it fits in with #1 to #10)

11. Advanced capabilities include: bi-directional data exchange with local and remote 3rd party systems and applications; predictive analytics for improved decision-making and consolidation of run-time data to a free-form-search corporate Knowledge Base that hosts corporate assets, strategies and KPIs.

All good? Not exactly.

My customers are right now scratching at the door, asking for total transparency in:

a) recording data/managing individual Cases at Cases
b) recording data/managing data at multiple Cases at Knowledgebases.

They want to manage Cases at Kbases. They want to manage Cases at Cases. They want the software to synch up and down.

Why would they NOT want this?

1. In a free-form search Kbase environment, you can search an entire space comprising customers, suppliers, sub-contractors, regulatory authorities (all separate entities, each needing their own RDBMS) and find things.

No more restrictions of having to expressly search the Phone Number field to find a phone number where someone could not be bothered to copy/paste a phone number from a memo field to the Phone Number field.

2. In a free-form search Kbase environment the results of searches show you what the search algorithm found and what it did NOT find.

Sometimes things you do not find are as important or more important than what you find, so hit/no hit searches are the way to go.

e.g. McDonalds today wants to set up a new outlet where Harveys' has no outlets. Tomorrow, they may want to set up a new outlet where Harvey's HAS an outlet.

Why do two separate searches?

The demand is coming from law enforcement where investigators want/need to focus on multiple cases at one time (spending a lot of time connecting-the-dots between cases) - forget data mining, these folks are way smarter than any analytics you can think of (at least until Watson goes through a few more upgrades).
  1. http://www.kwkeirstead.wordpress.com

Of course, none of these needs evolve overnight.

Civerex has been playing "spider in the web" since at least as far back as 2010, with our EMS concept (3D Kbases)

At the time, we had not heard of RBV (Resource-Based-View), circa 1959, it seems. The problem it seems is RBV was (still is) a great concept but in the absence of something like EMS it's not surprising that it never "got off the ground".

So, here we are in 2017, looking to fund an initiative that we conceptualized in 2010 and finally, in 2016, confirmed (to our satisfaction) a need for.

See "Theories of the Firm – Expanding RBV using 3D free-form search Kbases" (2016-07-08)

Does anyone at this forum have experience with RBV? If yes, I would be pleased to have comments.

Clearly, RBV comes from strategy whereas BPM is decidedly tactical but it seems to me you cannot be successful in strategy by ignoring operations, nor can operations succeed by ignoring strategy.
RE "recording" - considering that cases contain a lot of immutable information they become the basis for the records management. Also, an open case may use some information from some archived (in an RMS) cases. It seems that we need both - permanently enriching (versioning is important) knowledge base and permanently immutable info.base.
  1. more than a month ago
  2. BPM Discussions
  3. # 15
  • Page :
  • 1

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