Is BPM a subset of Case Management?

Sandy Kemsley recently related a quote from IBM's Feri Clayton regarding BPM:

“BPM is now considered part of Case Manager”

Could that statement possibly be true?!?!
Could BPM be considered to be a subset of Case Management?!?!
Will cats start breeding with dogs?!?!

Well... except for that last sentence, yes.  BPM is a subset of Case.  In fact, BPM is a subset of a lot of things - it always has been, and that's caused a lot of marketing confusion over the years... but very few practitioners have cared much about such distinctions.

Process is an integral part of virtually all Business Management scenarios.  In Case Management you're generally dealing with a Business Object, and there are many Processes that come into play over the life-cycle of that Business Object.

If we take a good look at any Business Management (software) solution, we're going to see these core elements:

• Business Objects
• Business Processes
• Business Rules
• Business Events

Changes to Business Objects are governed by Rules.  The state of Business Objects can trigger Events.  Business Processes are used to transform Business Objects. Business Processes can trigger or be triggered by Events... (You are also quite likely to encounter Business Monitoring and Business Analytics in your solution... But I digress...)

It's all very incestuous... 

Any non-trivial Business Management solution - and that certainly includes Case Management solutions - is going to have aspects of data, process, rules and events. Any Case Management System worth its salt is going to incorporate support for data, process, rules and events.

So yes indeed, BPM is a subset of Case Management.

The curious Case of the disappearing BPM Programmer...

I always enjoy reading through Adam Deane's BPM Quotes of the Week, and recently came across this great quote from Lynn Haber regarding BPM and Case Management:

“Case” and “process” are two distinct concepts. A case contains all the artifacts, including potentially multiple processes, associated with accomplishing a given piece of work. In contrast, a process is the path or paths that a case takes on its journey to completion. The process may or may not be explicitly defined prior to the case being started, depending on the type of work.

I'm going to quibble with Lynn's statement just a bit - 'a process is the path or paths that a case takes on its journey to completion' misses the mark ever so slightly because completion of a single process within a case usually doesn't "complete" the case itself... but that's just a quibble - Case and Process are distinct concepts.

Process is about transformation - In many processes you start with "something" and you end up with "something else" (a Loan Application becomes a Loan), but in Case you start with "something" and usually end up with the same "something" (but in a different state - such as updating a client's address).

Case is about coordination - Quoting Lynn again:

The best way to think of a "case" is to think about a coordinating object that has to be managed over time. The case folder is simply a single view into the data, tasks, documents and history of that entity.

Well put Lynn - Case is about managing "something" over time.

So where does this distinction between Case and Process leave the BPM Programmer?  Are BPM skills irrelevant in the new world of Dynamic Case Management and Social Process?  Are the BPM Programmer's skills doomed for irrelevance every few years just as the skills of System Programmers (C begat C++ begat Java begat Ruby etc.)?

Will BPM Programmers disappear into the mists of interesting but irrelevant oddities of the past?

Fear not, brave BPM Programmer - Your skills are safe.

Case without Process is like Process without Rules is like Rules without Events.  Everything builds on everything else when it comes to Managing a Business.

When push comes to shove, you never were a BPM Programmer -

You've always dealt with Business Objects.  Those Business Objects have always been associated with Business Rules.  Those Business Rules have always been evaluated in response to Business Events.  You've always dealt with coordinating changes to Business Objects by related but distinct Business Processes.

Nothing's changed dear colleagues.  Your job has always been about writing software to Manage Business.  Process is at the core of Business Management, but you always had to deal with Objects, Rules and Events.

You called yourself a BPM programmer, but in reality you've always been a Business Management Programmer (who was really passionate about Process).  The "P" has disappeared from our monikers, but we're still alive and well.

Big Government, Big Corporations, and Buggy Code

Off topic again... here in the USA the "left wing" has inevitably responded to the "right wing" - the Tea Party's conservative exasperation with big government has been joined by the liberal "Occupy" movement's exasperation with big corporations.

As a programmer, I'd like to councel both sides to step back and search for common roots for their exasperation.  In the heat of rhetoric it looks like these folks are in vehement opposition, but from a programmer's perspective it sure does look like the "bugs" in big government are closely related to the "bugs" in big corporations...

Programmers understand a great many things about "bugs"... In the context of our profession "bugs" are coding mistakes... "code" (aka source code) refers to the instructions that make up our programs... but in a much wider context "code" can be thought of as the mechanisms that guide everything.  DNA is the primary "code" that governs life, for example.

Programmers come to understand (through many painful experiences) that it is really, really hard to write "bug free" code (code that is not flawed).  Any code that is non-trivial will probably produce results that were never intended (side effects).  What seems like a perfectly straight-forward set of computer instructions can result in a hopeless or disastrous mess when executed.

Governments and corporations are also driven by "code".  Rules, regulations, laws, edicts, procedures... all contribute to dictate how governments and corporations "run".  Flaws in these rules, regulations, laws, edicts, procedures, etc.... Bugs in this "code" are what are exasperating the "Right" and the "Left".

The bigger the government or the corporation, the more "buggy code" there is driving it... and that's what makes it hard for policy makers to know where to start.  

Often times, well intended attempts to "fix" something simply "breaks" something else... Attempting to fixi what looks like a minor bug often unleashes a major bug to ravage the system.

Programmers (at least the good ones) deal with bugs by going back to the source... What was the intent in the first place?  What problems needed to be solved?  What goals needed to be reached?  Often the "bugs" in the system stem from from poorly crafted problem statements and goals.

In the case of "big corporations"... I think our exasperation stems from their basic goals and the mechanisms that are in place to achieve those goals...

Big corporations are "publicly traded".  Investors buy stock in the corporation in anticipation of periodic dividends that will be paid back to the stock holders.

Early in the life of the corporation, the funds raised by selling stock provide the capital that the company needs to develop and market its products... but once the corporation becomes mature the value of the stock effects the investors more directly than it effects the operations of the company.

Consequently, investors beat up on CEOs to keep raising the stock value, and to keep paying higher and higher dividends.

Fifty years ago, very few people invested their saving in stocks.  Most people saved their money in banks or purchased bonds (usually government saving bonds).  This changed dramatically in the 1980s when large numbers of people began to invest in Mutual Funds via their IRA and 401K plans.

Interesting digression: These charts seem to indicate that there is some correlation between the Mutual Fund ownership trend and the trend in CEO compensation (rather than corporate profit):

Mutual Funds are generally collections of stocks (and bonds)... They "make it safer" to invest by spreading the risk over a variety of corporate stocks, but they also make ownership extremely abstract.  Few people who invest in Mutual Funds have any idea of what corporations they are actually investing in.

Consequently, the investors in Mutual Funds have one, and only one, concern: The increase in value of their shares.  Anonymous ownership leads them to focus on profits - Even when obtaining those profits may be harming them in other ways...

Many people who owned stock in US corporations lost their jobs when those same US corporations "offshored" work to other countries.

Government rules and regulations spurred the growth of Mutual Funds... which led to irresponsible Investor demands on CEO's, which lead to "record profits for the rich" but also tremendous losses in "good jobs" and domestic manufacturing capabilities.

Said another way - Poorly thought out requirements led to the creation of "buggy" rules, regulations, procedures, etc - and a lot of good people got screwed as a result (and a lot of shady people disproportionately benefited).

Hopefully, those on the left and those on the right will all come to see this... "Patching" the "code" to eliminate the side effects just won't cut it.  Left and right need to join together to refine their requirements, accurately identify their shared goals and shared problems, and then "clean up the code".