By using a product to describe the concept of case management, the definition that Bruce creates is both clearer (with real world examples) as well as being skewed by the product. But don't get me wrong - Case360 is a product that I am still very proud of having been involved in, and I know for sure that it lives up to many of the claims. It is also a highly flexible and therefore often overly technical product, and for that it can sometime make the goal of case management harder.
What do I mean? For me, the fundamental attribute of case management is the flexibility it affords knowledge workers to do their job, using their knowledge of what needs to be done. A case management tool should provide a template for guiding work, while allowing 80% of this being unstructured work to comfortably sit inside (or on top of) the 20% of structured processing that exists. For me, the formality of BPM, modeling, simulation, optimization and all the rest, delays the delivery of a solution that should be largely flexible, collaborative and semi-structured. The structured stuff often gets in the way, or forcibly tries to take over the case working that needs to be done. This ends up with the (anti)pattern I strongly believe in: if it's not structured chaos, it doesn't need BPM. When processes get complex, its because they are not being flexible.
At the end of everything, the right tool is the one that workers adopt when they can use it to improve the way they work. I believe that the examples given by Bruce are hard to dispute. I also think that for similar requirements, there is another way. Am I being vague? Yes - and its intentional! Stay tuned...
A post from the Improving It blog
Coming soon... Download the podcast of this blog post