We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

What are the minimum requirements for case management?

Vote 0 Votes
An interesting question from Keith Swenson which is also on LinkedIn, what is the thing that truly defines something as being adaptive or dynamic case management and nothing else, or, as Keith says, "What it absolutely can not exist without."

10 Replies

| Add a Reply
  • I’ve been a big fan of Case Management – I still believe it’s what most customers thought they were buying when they bought workflow technology 20 years ago. I think the minimum requirements are dictated by what a customer wants to do – if the Case Management tool does that then it’s good enough – at least until the requirements change.
    But here’s what I really think – it’s an amalgam of several different presentations from a number of different vendors - http://www.slideshare.net/jonpyke/case-management-11899870

  • Hi Peter,

    This question has been plaguing the Adaptive Case Management discussion for quite awhile, and I think to its detriment. I'm sure that the BPMN vendors are bemused, by claims of patrimony, philosophical navel gazing and wonky implementation details.

    I applaud Keith's tireless efforts. We talked about a 'manifesto' last year, I hope that a core group of us like minded vendors can come together with a minimum agreement that helps us clarify the requirements and value proposition of ACM.

    At the implementation level, we are all quite different technologically, there is no underlying standard like BPMN binding us, so we need to find common ground.

    The minimum requirements for Case Management are a "Case", a notional bucket that holds process artifacts.

    The Case is managed by the process participants collaborating to meet a Goal as opposed to being driven by a centrally modeled procedural process.

    There are many advantages to being liberated from a flowchart, but those are not 'requirements'.

    In some productive exchanges from late last summer / early fall, MaxP, KeithS, and myself on LinkedIn where we tried to common up with a Solomon-like definition that would account for different levels of ACM, a maturity model of sorts, to enable ACM to be a 'big tent', while providing some minimal defining attributes.

    ACM Level 1: Case, a user-own container for organizing and collaborating on process artifacts to move towards a goal.
    ACM Level 2: the ability for Case owners to link to business 'objects' for purposes of leveraging normalized definitions and useful functions.
    ACM Level 3: The ability for Agents to connect the dots between Cases details (personnel profiles, attachments, metadata, business 'objects') to recommend next best actions.

    This is my purposefully simplified rendition. I do believe that being clear and concise is key to defining the category.

    On that note, I don't think the ACM 'movement' should live in fear of interlopers who make false claims about their ACM status, wasting time on litmus tests of 'purity' is silly and counter-productive. Yes, BPMN vendors will and already are using marketing to drown and/or co-opt the ACM term - big deal. I don't think we want to certify membership. Let's get over it and assume the intelligence of our customers to separate wheat from chaff, after all, a core tenet of ACM is empowering people.


  • And again I experience the same mix up between Case Management and a Case Management System.

    So are we talking about the requirements of a CMS?

    Or is it about more fundamental (and to me better) questions like:

    - What is a case?
    - When is it useful to manage work as a case?
    - What is needed to manage a case?
    - Is specialized tooling really needed (or can an ECM help us)?

  • As Dave points out, case management can in fact be done with a very minimal set of capabilities. You need a "case" which is a place to put things, and an acknowledged goal. Of course, case management can be accomplished with a pencil and a manila folder.

    The problem many products that call themselves case management solutions, is that they have too many capabilities that to use them you have to be a "case management specialist" which is a kind of programmer.

    Case management is what the case manager does. It is what the lawyer does, or the doctor, or the judge, or the social worker.

    The critical aspect of a system to support the case manager, is that when the case manager realizes that something new needs to be done, that has NEVER been done before, they can instantly create a goal/task to represent that.

    How many presentations have I heard where the presenter in an entirely straight face says that "any task can be added at any time". When pressed, they admit you have to use a special "modeling tool" in order to add such a task. These professionals are so busy they will never use a modeling tool. We are not looking for the ability of a programmer to add a task to the system. Any barrier to the case manager to adding a task will result in the case manager using AN EMAIL instead of using the system. If they have to ask a programmer to add the task, then they will just use email instead. This is really important!

    The problem is that these system try to do TOO MUCH, and in adding all the capabilities, they increase the complexity above what a typical non-programmer professional is willing to learn. Doing this removes the system from suitability for case management.

    If you get a bunch of technologists together to design the best case management system, they will insist on a list of features and capabilities that by their very presence remove the system from usefulness by the very case managers they are supposed to be addressing.

    Perhaps we should be asking: what is the maximum set of capabilities that a case management should have?

    What really distinguishes a good case management system, particularly an Adaptive Case Management System, is "design" such that it can be used by non-programming professionals. Design such that we experience in the iPhone or the iPad that make completely new genres of technology devices because of their outstanding usability. It is not because the iPhone had more "features" than the Blackberry. It is because the iPhone was more usable. You don't ask the question whether the iPhone had the minimal capabilities of a smart phone. It is very hard to make a precise definition of the elements of usability and design.

    Thanks again Peter for the referenced link and discussion. http://social-biz.org/

    • Good points Keith.

      And that is why most of today's Case Management Systems are actually nothing more than Adaptive Process Management system.

      They allow you to follow different paths, depending on the case, but these paths have to be predefined (read: modelled).

      Case management is about uncertainty in what will happen for a specific case. So how do you manage uncertainty? Probably most by using the tool that can be found on the top of your neck? ;-)

  • Hi Emiel,

    Cases have advantages as Keith and many others have laid out many times, but there are reason (reporting, compliance and convenience) that Case users might want to leverage some modeled capabilities.

    A "Case" is a tool, it is clearly not salvation. Let's not be guilty of the same "I'v got a hammer, everything is a nail" dogma that the BPMN guys hoisted on the world.

    I don't have any issue with folks offering simple Case Management tools, in some cases, that's all the customer needs, but not all.

    Work is a continuum, from ad-hoc all the way to procedural, we support both extremes and any variant inbetween - let Case Owners and/or business context decide.

    Personally, I submit I believe the ideal is a system that can support all three levels I identified above from an 'empty' case to agent-based support. Of course, if another vendor wants to offer and excel at just one aspect, more power to them - vive la difference!

    I'm hoping we can get past religious wars and focus on a definition of ACM once and for all, otherwise this is just a tempest in a teapot, navel gazing by the ACM illuminati.


    • Dave,

      I agree with your ideas on supporting tools for case management, but your sentence 'a "Case" is a tool' might cause some confusion for the ones who just start investigating case management.

      Maybe it might be that I don't understand the translation of the world tool, but to me a case is the thing that happens and need to be solved. I always like to take the example:

      "Emiel goes to see the doctor because he is having an headache for 3 weeks now"

      So the case is "Emiel with his headache". To serve/help/solve this case a lot of (upfront unknown) things might happen and are needed:

      - Depending on my case several processes might be kicked of (mri scan, taking bloodsamples, surgery)

      - A lot of information might be needed and gathered (research results, x ray, bloodsamples)

      - Different (highly skilled) employees will handle the case. They all need the right information

      -Different solutions might be tested and the results will define the next steps.

      So a case is definitely not a tool (or you must like to say that Emiel is a tool ;-).

      And of course for handling cases employees might need tools for collecting information, handling a process, taking decisions, register progress.

      And that sounds a little like your level 3.

      Again, it might be because I don't understand the translation, but saying a case is a tool to me sounds like saying 'building a house is a hammer'

  • Eric Armstrong here. Just wanted to applaud Keith for his comments on usability. (Have so far been defeated 9 times in my attempts to register. Talk about a usability gap! But I'll try a few more times and see if I get lucky.)

  • Emiel - I'm at a conference so I'm writing in shorthand for the ebizq audience, but I think you get the gist of the points of making. Yes, Case Management is an idea independent of software systems, but the subject of this thread is requirements for a Case Management System. Level 1 that I propose could conceptually be handled in a paper or electronic fashion, the notions in level 2 and 3 presume systems to manage the complex interrelationships.

  • I do not understand why someone who considers 'ACM illuminati' being busy with useless navel gazing and wonky detail wants to be even involved with the ACM concept. A manifesto would be just doing the same thing: detailed introspection to clarify. All software market fragments have to deal with 'interlopers' and no one fears them but everyone loathes them and because they are a fact of life simply deals with it. If we stay away from a better specification and explanation of what ACM does how and why, prospects won't understand why to even bother.

    Some principles:
    !) Case management has actually very little common with Adaptive Case Management, except for the name and the idea that it holds all resources pertaining to various units of work. ACM is closer to CM than to BPM with its more ad-hoc nature. ACM is a form of BPM too, but it does away with the BPM bureaucracy needed for implementation.

    2) The case folder isn't a folder or bucket in ACM. That shows a lack of understanding or poor choice of words. Yes, it is a logical bracket the holds complex semantic (not just is-contained-in) relationships to case resources. The key aspect of it is not the entities used, but the life cycle, meaning as to which skill of people can perform which actions at which point in the case how. ACM should link everything together and empower case workers to do everything necessary to achieve explicitly defined goals without needing an IT or BPM specialist.

    3) I have started to define ACM levels to try and allow multiple approaches to ACM that would go to different depth in different ways. The alternate suggestions of levels takes basic case management functionality and just spreads them out. ACM is a lot more than that, but as we shouldn't discuss wonky details I won't say why.

    Finally, I have suggested a professional and more scientific approach to ACM through defining an ontology of terms that encompasses a link to Business Architecture. The suggestion was politely ignored so far, but I am nearly done with a paper that will suggest a basic ACM ontology as 'business language of process' and hope to present it in the next few weeks.

    Why discussing BPM in the light of ACM:
    Orthodox process management lacks knowledge from the worker. Analysis extracts the 'how' but not the 'why' as it can't be encoded in flows. 'How' is historical information that cannot necessarily be reapplied to create the same outcome. 'Why' is the causal information that leads to goal achievement and is an intuitive aspect of work. 'Why' defines which 'how' to use to achieve the goals. To apply knowledge means to have transparency of the case state and most importantly its context. The primary purpose of ACM is to enable the worker to utilize his knowledge by getting context transparency and to capture as much of it as possible into ACM templates. Neither CM or BPM do anything of the kind.

    Does a system do that without needing bureaucracy, programming or IT experts? Then its ACM!

Add a Reply

Recently Commented On

Monthly Archives