I’ve long been niggled by a nagging doubt about the term ‘Case Management’ and how it gets introduced and explained. A lot of people I talk to outside of the legal sphere find it confusing; those I’ve talked to in legal circles have overly specific ideas about what it means. Because the words are often found in the vicinity of the words “Business Process Management”, I’m finding that this can also lead people to make assumptions about Case Management that aren’t necessarily helpful.
Business Process Management itself is an odd beast with three legs. One leg is an approach to managing a business—by using systems business processes as the linkage between strategy to operations, as the framework for how you look for opportunities and challenges. The second leg is about using specialised modeling tools and platforms, principally, to support this ‘management system’. The third leg is about using a broader set of development and analytics tools and platforms to create operational ‘process applications’ that distribute, co-ordinate and monitor work in line with the intent of your management system.
Case Management is a different kind of beast. It has just one leg, really—which looks a little bit like BPM’s third leg. From a distance. But when you get up close you see that Case Management’s one leg has a few more joints, and the leg moves about in quite odd ways (if you’re used to seeing very solid, structured legs anyway).
But enough of this talk about legs.
What I’m trying to say is that when we try to explain the current shifts in how work is being supported with technology by immediately launching into labels like ‘Case Management’ (whether Adaptive, Advanced, Dynamic, Production, or perhaps mint-choc-chip) and ‘Business Process Management’, it’s confusing. This is not least because Case Management, at least in the way that the term is most often used, is principally a style of model-driven application implementation supported by specialised tools. Case Management doesn’t have anything direct to say about business management systems, by and large, and there’s no modeling or improvement Body of Knowledge in the same way that we have a BoK around techniques like Lean and Six Sigma.
Some of the more recent discourse around distinguishing Case Management from BPM has been framed by contrasting ‘structured’ and ‘unstructured’ work, and I think this is a bit better—because at least it attempts to get away from product category labels and distinguish approaches more according to the kind of thing that you might want to achieve.
But I still think—and this is really where my niggle persisted—that this is a bit too architect-y, a bit too techie. We’re distinguishing types of work in terms of how that work is arranged in a very static, diagram-drawn-on-a-napkin kind of way.
I believe it pays to try and take this a bit further and use terms that describe how different types of work actually feel—to people participating in the work and to people on the ‘receiving end’. So when asked to explain what all the fuss is about re: Case Management and BPM, I talk first about transactional work and contrast that with exploratory work.
Transactional work is work in which the inputs are well-understood, the outputs are well-understood, and there’s a strong correlation between carrying out a very clear, particular set of actions and consistent transformation of those inputs into those outputs. Transactional work is not necessarily simple; it can be complicated and involve many teams of people, and might need to be done at massive scope and scale. Some discretion will be required to resolve unexpected challenges along the way.
Exploratory work is very different in the way that it feels. Exploratory work is often what lurks underneath verbs like “resolve”, “diagnose”, “fix”, “co-ordinate”, “solve”, “determine”, “arbitrate” and so on. The inputs to exploratory work may be broadly categorisable, but are probably not completely predictable. The outputs are likely to be well-understood in terms of high-level goals (see the verbs above), but probably but not in terms of tight specifications. And most importantly, the set and sequence of actions needing to be performed, and the people or roles needing to perform them, are very unlikely to be known ahead of time. There may be some high-level waypoints or milestones that are common to a particular type of exploratory work (perhaps to ensure consistent quality control, or resolution approval, or archiving) but they provide a very loose, rather than tight, structure. In exploratory work, as the label suggests, the overall experience for both the work participants and the customer is that of a set of possibilities being explored rather than a recipe being followed.
Exploratory work is often the natural work form in key parts of a business that touch customers—but many corporations have tried to engineer out the variances, eradicate the exceptions and force-fit natural interactions into transactional boxes. In the age of the customer and as we witness a shift towards truly Digital Enterprises, we can’t afford to ignore the potential upside of supporting exploratory work with specialised tools that make it more effective, more efficient, less error-prone and more improvable without reducing its nature. This is where good Case Management technology comes in. Cases are management structures for exploratory work.
What I’m finding is that by focusing first on helping people think about the richer nature of different styles of work for different situations, and not just focusing on labels like structured and unstructured work, it makes the explanation of Case Management much easier.
I’d love to know your thoughts on this. Does it make sense? Do you use this kind of explanation?
We automatically stop accepting comments 180 days after a post is published. If you would like to know more about this subject, please contact us and we'll try to help.