It is time for a clear definition of Adaptive Case Management (ACM) which is stated in a way that one can tell whether a particular system is an ACMS or not. This post is an attempt to clarify that. It is intended as that starting point for a discussion in the Linked In ACM Group. (Linked-In makes it difficult to make long posts, so I put it here, password protected, for the time being.)
I am inviting comments here or in the linked in group from anyone who wishes to participate. This is not final! Please send comment oriented toward:
- additional requirements that an ACM system MUST meet
- a good example of how a particular requirement is not required.
I am aware of and wish to avoid the “kitchen sink” syndrome where one is asked what they would “like” to see in a system, and this leads to an endless list of cool capabilities that it would be nice to have. The test is not what a system “should” but rather what it absolutely can not exist without. I have my pruning shears and I am in the mood to trim this definition to the bare essentials. As Einstein said: Everything should be made as simple as possible, but not simpler. The definitions are designed to be a minimal as possible, and yet still be accurate.
We know that ACM is to support knowledge workers, and we know that having to go to a programmer to change things will prevent knowledge workers from having the flexibility they need. From that we can surmise that certain characteristics must exist. I broke the definition into three levels in roughly the same way that Max Pucher did in his post “Adaptive Case Management: Basic, Full, or Strategic?“ All ACM Systems MUST have level 1. Many will have features at level 2, and only some advanced ones will have features at level 3.
Adaptive Case Management is an approach to work that supports knowledge workers to get their work done. A software system must support the following capabilities in order to be called an Adaptive Case Management System (ACMS).
Team: It must organize the work of the knowledge worker (called a case manager) and also others involved in the case (called the case team). The case team is not predefined, and one of the jobs of the case manager is to identify people who are appropriate to help on the case.
Folder: The central concept is a case folder that is used to collect together all of the information and artifacts that might be needed by the case manager. There is no predefined collection of information; part of the job of the case team is to locate and collect the necessary information for the case, and put it in the folder.
Goals: To drive the work to completion, the case team communicates about goals (also called tasks), intended and actual timelines for performing activities toward those goals. None of the goals are fixed: any goal can be modified, added, or removed by the case manager without special skills.
History: The system keeps timestamped records of every change that happens in and around the case.
Security: The case manager is in complete control of who is authorized to access the case folder. Unauthorized users can not access the case folder.
Communication: The system must facilitate communication between case members through multiple channels: telephone, email, instant message, desktop conference, and other technologies.
Adaptive: The case manager can make new cases that build on structure of previous cases through some form of copy or reuse of the earlier cases without needing any special skills. Over time the case manager will adapt the system to their own style of working without needing the help of any specialist.
Reporting: A large variety of user configurable reports for communicating status, things that have happened within a given case, and aggregate information across cases.
Business Entities: Structured data with metadata behind it. Form capability to display and allow entry of business data.
Data Interchange: ability to access systems and internalize this within the business entity format for reuse, and the ability to transform the internalized data to a form to send to an external system.
Business Rules: Generalized rules mechanism that tests the business data for specific conditions that can either trigger activities, or effect the state of resources.
Resource State Model: Files and other resources can have a state model associated with them. Transitions between states can effect and be effected by other resource state changes.
Granular Access Control: Fine ability to control who can access what parts of the case information through the use of roles into which people can be assigned.
Sensors and Triggers: the ability to monitor external data / state, and the ability to trigger reactions that change the state of internal resources or goals.
Conformance Guiding: the ability to match the activities of a current state with a reference process, and provide a visual difference highlighting extra or missing activities, order disparity, and make recommendations on how to conform.
Process Mining: The ability to analyze the history records and to generate process maps showing the patterns of behavior across many cases.
Social Mining: The ability to scan networks of connections between people in order to determine skills and/or preferences of people, in order to guide assignment of activities.
Federated Case Folders: the ability to link folders in one case system to folders in another system, and synchronize content in both directions
Ontology / Taxonomy: represented in standardized form and able to exchange with knowledge management systems.
Resource Sharing: a given task or resource could be shared between multiple cases.
Call For Action
Agree? Disagree? Can you put into clear words what must be required of a system to be called an ACMS? Please put comments here, or in the Linked-In ACM Group.
Update – Comments
After a good discussion on Linked-In, I summarize that discussion below. Comments fall into two categories. (1) direct suggestions on how this might be modified, and (2) bigger scoped comments and discussion on what we should be doing additionally beyond this.
- reporting is missing – good catch, I added this.
- goals are there, but tasks are missing from list and should be there – I don’t want to split hairs or have long drawn out discussion of the semantics, but from a knowledge worker perspective, remembering that the target user is a non-technical business person, I am not really seeing a big difference between a goal and a task. A task might be “file an extension form”, and a goal might be “file an extension form”. A task might be “proofread the document” and a goal might be “proofread the document”. A task might be something really fine grained like “print out a hard-copy” but a goal could similarly be “print out a hard-copy”. If you have a task to do, you express it as a goal. I don’t see that there is any real need for a difference.
- what about the system being self-adaptive? Is that missing? – This discussion centered on making a system that would by itself sense things and adapt itself to the incoming sequence. This is a cool idea, but I just don’t see knowledge workers doing such a thing. I can see programmers designing and implementing this kind of pre-programmed capability, but it falls outside of the scope of what one can expect a business user to do.
- data interchange ok, but need to also be able to understand the data – This is a very good point, and relates to level 2 business entities, and level 3 ontologies, and so I am not sure that any particular addition is needed.
- business rules are more important and should be at level 1 – Reasonable suggestion, but upon reflection, I still see rules as being a programming activity that the individual knowledge workers will not often engage in, and thus I can easily see systems that support case management that have no automated rules capability. The creation of rules implies predictability: you predict that on a particular situation you will want a particular response, but the nature of case management is that each case is unique and there are aspects of the case that are not represented in a form that could be tested by a rule. I don’t argue against rules, I just see this as a level 2 capability.
- need sensors and triggers – I can’t see a business user setting up triggers for events. In case management, the effort required to set up a trigger condition is significant, and works only if the data is represented in a uniform way from case to case, and that all the relevant information is available to the trigger condition. Then you have to consider how many cases will benefit from that action, and weight that against the effort to just make that judgement manually. Sensors and triggers is not in the scope of what a business person will do.
- need conformance guidance – this is already there at level 2
- social mining is part of process mining – perhaps we should not break these into two cone might combine these into a single capability, but the kind of social mining I have seen discussed is not mentioned in the process mining manifesto, and so I think it is worth having an additional point at the level 3 to make this clear.
- resource balancing is missing – resource balancing is a kind of business rule where a condition is specified upon which roles and responsibilities will be redistributed. In real life, deciding who is going to take over what case is a very complicated and subtle activity. Your average business person is going to want to be directly in charge of re-allocating tasks to people. It sounds like a great idea to “automatically” allocate work to people, but anything automated needs to be done by a programmer. I don’t see business people doing this sort of thing. Instead, I see them manually reallocating tasks, and using their own unique knowledge of the situation and the people involved to do it. Extracting the rules to do this automatically is much more work and much more problematic.
Indirect Comments on Further Directions
- what tools need to do to support ACM is valuable
- this is not same as components
- need a reference architecture of ACM
- need a clear definition of a case & case management that stands on its own
- case definition: a place to store things, and represents an instance of a goal
- principle: must be electronically accessible
- principle: must be a permanent indelible record of versions of everything
- principle: audit trail is not sufficient.
- convenience: need connectivity to external worlds for import/export/linking
- unclear: relationship to role
- principle: do not establish 1-to-many relationships
- principle: there is a natural nesting of cases which is complicated
- concern: some complexity due to legal constraints on sharing information
- definition should distinguish from things that are not cases, like carpenter’s toolbox or relational db
- definition: case defines a set of relationships and must have a goal
- ACM is about embedded learning
- principle: must handle signatures (proofs of particular things)
- principle: copying between cases can be very sensitive
- concern that the exact definition of ACM may be harmful or inappropriate
- should consider a discussion of values
- the great problem with knowledge work is that our management models are incorrect
- lot of focus on feature sets before defining what the jobs-to-be-done are
- concern about an “exact requirements definition”. It’s the word “requirements”.