Requirements for Case Management – Case Folder

When the WfMC got together in November 2009 to discuss case management, it was with consumer clarity in mind, not a desire to muddy the waters of the software segment called BPM.  Much of the discussion was on whether or not there was a distinct set of technology requirements, whether it was separate from or complementary to BPMS, and whether it was different than what we all thought of as case management back a few years ago.  The short version is that many felt that it was distinct enough from BPMS to name it Adaptive Case Management (ACM), and that it was an evolutionary jump from the case management of old.  Whether ACM is completely separate from BPMS or not was a little less clear with some believing that ACM should stand alone and others (myself included) believing that ACM benefits from incorporation of BPMS features, acting as an umbrella solution of sorts.

Since that meeting, and more so since the launch of “Mastering the Unpredictable”, there has been a healthy set of conversations on what the difference really is between ACM and BPMS.  Note that I’m focusing here on the technology solutions referred to a Business Process Management Suites (BPMS) not the management discipline of Business Process Management.  I’m making the distinction to help answer questions folks have asked like “What is the technical difference between ACM and BPMS?”  My plan is to highlight a few key features, some of which were discussed in the book, some not, in a series of posts like this.  First up is probably the most obvious and possibly one of the most misunderstood, the case folder.

You’ll hear a case folder described in a number of ways, possibly the most common of which is as a “virtual manilla folder.”  The manilla folder analogy works, especially when you think about taking a series of documents and putting them in there, marking up a couple of them and taking some notes, maybe putting a few sticky notes on the outside, having a routing sheet that designates who gets the folder next, and maybe even a little checklist (if you’re advanced) with all the things that need to be done at each step in the folder’s journey.  Now picture someone from the mail room with a big rolling cart collecting the folder from your desk and taking it on to the next person, cart overflowing with folders, all of which will (hopefully) get to their destinations.  Hopefully everyone has a good mental picture of this way of working.

Now translate that picture into technology.  I need a case folder that can hold more than one document (preferably an unlimited number) from any number of different sources.  The case folder really should understand that the documents inside it each have meaning, i.e. an application is not always treated the same way that a contract is.  Any of those documents should be able to be annotated, redacted, scaled, rotated, etc., because when paper comes into the enterprise it isn’t always perfect.  Speaking of paper, we’d like to get rid of it entirely (not just scan it in once it hits the system) so the case folder needs to treat scanned images as equal to electronic forms and allow a mix and match of both.

In addition to supporting content, the case folder needs to have configurable data associated with it.  No two case folders are exactly alike across two implementations, so being able to define the data specific to your solution is critical.  In fact, most case management solutions are very data-intensive, so this is of particular importance.  

But Tom, these both sound like features found in my BPMS (perhaps through a “casefolder activity”), or even through a document set in Microsoft Sharepoint 2010.  True, in some fashion you could use either of these solutions to approximate what we’ve defined as a case folder so far.  And even when we add Tasks, Discussions, History, Assignment and Security, we’re still likely going to hear folks say “yes, but I could do something close to that in my XYZ system.”  So while these are absolutely critical capabilities of a case folder, what does ACM require that most (if not all) BPMS do not support?

The case folder must be able to stand alone.  That means that I shouldn’t have to create a process map, no matter how simple, just to define a case folder template.  That’s sort of like having to click the “Start” menu to get to “Shutdown” on your PC.  

Why is this important?  Because a case folder represents a relationship, something that is likely long running and persistent.  In most situations the case is used to coordinate activity like handling an exception to a claim, or processing a policy application, but often enough the case is also the permanent record of a business entity like an employee (think employee lifecycle management), an application (think insurance policies), a customer (think 360 degree view of your customer and all their accounts with you), or even something like an actual case, i.e. a legal proceeding.  

Now, there are times when a case will need to go through a process, where the process should be able to coordinate the flow of the case to various parties, and I think it’s critical that your ACM system can provide this capability.  For an employee it might be an “on-boarding” process, for a customer a “new account opening” process.  I still want to use the case folder as the view into each of those, but I may have a milestone based business process that I want to guide the case through.  If the case is forced to live in a process for technological reasons, how do I run that case through my real process?  Do I push a process containing a case through another process?  I can barely picture that myself and I know what I’m trying to say.  I would argue that the complexity this creates is unnecessary and only serves to complicate solving my core problem.

So does the case folder stand alone?  I think so, but I’d also like to hear your thoughts, so please do comment below.  I’ll try to pick off a single differentiating feature now for discussion over the coming weeks, so stay tuned.