Case design

Nowadays most organizations provide customer centric services. Customer interactions are personalized: emails are started with my name; I get personalized offers; and more. But, how customer centric is this, when the processes, information and cases are the same for all (potential) customers? Are these really customer specific, or can I slap any name on any case?

What is a case?

Several definitions are available for case:

• NORA (Dutch Government Architecture Reference): “A coherent amount of work with a well-defined reason and a well-defined end result, of which quality and lead time must be monitored”;
• Intelligent Information Management Glossary: “A ‘case’ is any project, transaction, service or response that is ‘opened’ and ‘closed’ over a period of time to achieve resolution of a problem, claim, request, proposal, development or other complex activity. It is likely to involve multiple persons inside and outside of [sic] the organization, with varying relationships to each other, as well as multiple documents and messages”;
• Exetie: “A ‘case’ is a compendium of information, processes, advanced analytics, business rules, collaboration, and sometimes social computing that relates to a particular interaction with or issue involving a particular party like a customer, supplier, patient, student, or defendant. The case file will involve a collection of customer communications, forms, process documents, reports and supporting documentation, and will need to be managed for compliance and audit”.

Extracting the defining elements from the above definitions, a case:

• has a well-defined end result—that is, at most 1 end result. This ensures that the status of a case can be unambiguously determined. Several decisions can follow from 1 case;
• has a well-defined reason to start. A case must be conducted for a reason;
• (can) cross organizational boundaries;
• concerns multiple documents, users, rules, messages, etc.

The process

As explained in my previous [post](business modelling), I don’t look at processes in the traditional “flow charts” way. I look at process using the flows from cooperation and communication, as described by Winigrad and Flores in “Understanding computers and Cognition” (abstract). This leaves room for dynamic adaption of the tasks to be performed to complete a case. And therefor has the possibility to personalize the whole process and not only the communication, as usually done nowadays.

A case process starts with the unambiguous information need of the initiator, which is fulfilled by the product delivered by the case process. To determine what the unambiguous information need is, the reasons for this information need must be determined. If there are multiple possible reasons (and there is always only 1 reason at a time) to start a case, this is probably the information need that will start the case. E.g. a police visit or inspection at someones property may be started as a result of a report of someone, as a result of a court order or as a result of an impromptu decision by a police officer, due to the circumstances. Due to these different reasons to start an inspection we separate the prior case (the report, the court order or the impromptu decision) from the follow-up case (the inspection).

And, to repeat myself, where I say process, I actually imagine a bunch of ad-hoc tasks presenting themselves when necessary to fulfill the information need of the initiator.

Case dossier

First, it is important to understand we build a case dossier, potentially consisting of multiple documents (or files); an audit trail consisting of the steps we performed; and documenting the result (the decision made in the context) of the case.

The case is often opened, and updated by the executor (although with self-service internet sites, and all the “my”-portals this is shifting). The executor determines which actions to perform and which information is necessary to fulfill the request in the best way possible (both in performance as well as in fulfilling the information need). As can be seen from this description, one of the important aspects of the executor is to determine the best path through the whole process. Performing this task analysis backwards is very beneficial, as opposed to determine the tasks upfront. The executor determine what information is required to fulfill the request and determines what information and/or action he needs to provide this information. If he misses information to fulfill one of the prerequisites, he determines what information and/or action he need to get this information, etc. This backward tracking (or declarative process models) provide the flexibility needed to support knowledge workers and provide for a customized, customer centric, business process.