I’ve been reading Mastering the Unpredictable: How Adaptive Case Management will Revolutionize the Way That Knowledge Workers Get Things Done. This interesting book brings several current topics together, including complexity theory, business process management (BPM), and the evolving practices around knowledge work.

Adaptive Case Management (ACM) argues that in knowledge work, processes need to be much more flexible than in transactional work. Case management as a paradigm originates from practices such as law and medicine, where no rigid process model can accommodate the complexities of a given engagement with a client or patient.

Instead, the concept of “case” is used as a high level container for various activities and artifacts. Choice of whether or not to perform a given activity is often in the hands of the participants, execution paths may differ from case to case, and in general ACM seeks to be a more flexible paradigm supporting greater process complexity.

ACM is also presented as more information-centric, although that information is often unstructured.

There is much definition and comment on the Web (see this set of BPTrends articles, and this article from Max Pucher), and analyst firms have started to track ACM as a market segment.

My interest is in the intersection of IT service management and case management. I’ve proposed elsewhere that there are relatively few true IT processes, if one insists on a strict criteria of countability. ACM does not override the criteria of countability; either there is a case or there isn’t. However, if we look at the major, countable IT processes such as Incident, Change, or Problem, it’s clear that they all have aspects of case management.

No strict, prescriptive, step by step flow chart could ever hope to represent the various diagnosis and resolution activities technical staff may follow for Incidents, or assessing Changes in general. Attempts to implement overly rigid, fine-grained BPM approaches in ITSM processes fail because of this.

This does not mean that process thinking has no place. Even in flexible cases, certain business rules and states may be required. In Incident Management, one should triage before going to resolution, and the fact of whether the Change is complete must be clear to all participants. But drilling too far into procedural details leads to the notorious dusty 3-ring IT process notebooks on the shelf – or nowadays, stale Sharepoint docs.

The practical alternative in many situations is narrative: the time-honored logging of status updates for an Incident or Problem. This works well enough. In fact, a large granularity process accompanied by detailed narrative status updates I would argue is a de facto sort of ACM. Repeated Incidents that have a documented knowledge base (KB) article would seem to be a form of ACM template.

Can ACM practices benefit IT service management? Should (for example) KB articles actually *be* ACM templates? What about making complex IT infrastructure provisioning more manageable? Can we refine the ongoing stream of status updates on an Incident so that analytics can be more readily applied to understand execution? ITSM process mining, anyone (also here)?

Very interested in hearing your thoughts.

Enhanced by Zemanta