Agreed w/ your comments about Case Management (approach) and Case Management (software). Regarding the BPM/ACM separation, I think the tools need to adapt to allow either a structured process to drive more ad-hoc (case management oriented) subprocesses, or to allow ACM to drive more structured subprocesses (pieces of a more flexible whole). Clearly the best answer is for the tools to handle both well. This isn't too dis-similar to arguments between BPM and SOA – which one is the tail and which one is the dog, so to speak :) I'm not sure that it matters vis-a-vis ACM and BPMS – but ideally you want support for both.

Tom, funny enough, coming back to this and reading my own earlier comment I found I need to offer clarification to the comment that “if a process is complex it isn't the tooling that makes it so” – of course, the caveat to that is that the “best-fit” tooling for a particular problem yield simpler solutions (don't add complexity, or abstract complexity in useful ways) than tooling that isn't a best-fit. So while BPMN doesn't “create” complexity, I think other approaches (JJ's resource based modeling, or ACM, or even rules) will offer best-fit for other situations. I think Jacob's point is that his own product line is geared toward allowing the business to own their own process definitions and execution (good enough for simpler processes). Because these processes won't be highly defined ahead of time, they'll look “simple” ahead of time, though the actual execution path, and the software to make that work, may actually be quite complex. I think clearly ActionBase fits case management use cases – but I leave it to Jacob and/or you to say whether it fits the definition of ACM (or even, more precisely, what the definition of ACM should be vs. Case Management)…

The concerning comment for me in this conversation is “I am hoping that ACM will enable 'good enough' process management for simpler, non-automated (i.e. human) processes-enabling business people to own, manage and modify those process themselves.”

ACM isn't about dealing with simple processes, quite the opposite actually. I believe that ACM should enable support for the most complex processes, those which are often impractical to model / capture in a traditional BPM suite.

When I say this, I'm not thinking theoretically, rather looking at this from a point of view of what is practical. There are business scenarios where it is simply infeasible to predict and therefore predefine, all the possible choices and outcomes of a given process. If you want to read an objective example of this, take a look at the comments section on the following post: http://www.tomshepherd.net/?p=118

Scott, you raise a very good point on the separation and distinction of ACM from BPM by certain ACM advocates, which I'd like to explore a bit. From my experience, most BPMS vendors are not typically able to support Adaptive Case Management. Sure, many add case folders and task lists and some level of collaborative tasks (like your example of an “out” to sharepoint within Lombardi). In the end though, the structured process is the coordinating object. In ACM, the case itself can be (and typically is) the coordinating object, and lives on after the process has ended. Think of it as an inversion of the work item / process instance and the case folder.

Back to the separation of ACM and BPM at a functional level, I don't believe that the two have to be separate and independent. My feeling is that you need structured process within the constructs of ACM to deal with the more structured case management problems, and to bring repeatability to some of the more routine aspects of knowledge work. After all, very few scenarios are truly 100% unstructured / non-repeatable.

One of the other topics that I've raised recently is that Case Management solutions and a Case Management approach are not one and the same, much as there is a distinction between BPM and BPMS. Which is why I'll agree with you and say that most organizations will want the benefits brought by both ACM and BPMS, although time will tell whether we'll see it called BPM or something else (doesn't really matter to me).

While I don't see traditional BPM suite deployments, properly managed, going the middleware route, if you hand software to middleware IT guys… guess what they'll do with it :) The risk you describe for BPM suites is real.

It really requires different thought process and method for deployment to get the right collaboration between IT and Business to get processes deployed with BPM Suites. This is the same collaboration that should exist for ANY IT project, but BPM suites at least make it possible for them to communicate more clearly.

The growing complexity of BPM suites is a benefit for IT staff – it is now easier to implement complex structured processes, but the downside is that BPM suites are now a developers tool – not a business tool. So I guess the questions are – Who are the intended users of BPMS technology? Who owns the processes that are created?

It seems clear that many BPM suites are going down the road of middleware – becoming a platform enabling a sophisticated IT staff to create better business process solutions more quickly – which means that IT is in charge of managing, maintaining and evolving those process and making IT the defacto owner of the process.

Though that wasn't the original promise of BPM suites (they were hoping to enable business people to build and own processes themselves), it does makes sense for the automation of complex structured enterprise processes – but opens the door for new lighterweight, good-enough tools for other processes (either not as complex, or not as automated).

I am hoping that ACM will enable “good enough” process management for simpler, non-automated (i.e. human) processes-enabling business people to own, manage and modify those process themselves.

Of course, I think there's a great market for making simple processes “simpler” to manage (or make). ACM (and ActionBase itself) are really good examples of this.

What I worry about is when people insist that BPM (or BPMN) unnecessarily makes processes complex – if the process is complex it isn't because of the tooling, its because of the process. (An exception to this is when there is a serious impedance matching problem between the tooling and the process, but I don't think that's typically the issue with BPM).

There are two parts to achieving this goal:
- Tools that make managing simple processes simpler
- Teaching people how to simplify their processes

I worry when people insist that their processes are “really really” complex – and I worry even more when the tool vendors cater to this notion. “You want to build an unpredictable and infinitely customizable process?” – “Have we got the tool for you!”