There are many uses of the term sense
making as phenomena in the literature
(spelled myriad different ways) which have no
relationship to Sense Making Methodology.
Automating or designing business process is primarily a technique to convert embedded knowledge and tacit knowledge into procedural chunks of work. The tacit knowledge is extracted from experts (knowledge workers), while the embedded knowledge is what has grown over time via practices and policies of the organisation. This embedded
knowledge is effectively of the “… the way we have always done it…” type. Whatever the pros and cons of procedural or checklist type break down of tasks, it does provide a tool, albeit a simple one, to take a stab at understanding the business process. This technique is applicable to a large number of front office and back office processes.
- Consider an insurers claims process, which has a simple, a complicated, and a complex component. The component here refers to a particular path in the process. Very small claim amounts cost more to process through the usual channels than is justified. And delays in payments can be very costly to the claimant, and if it happens frequently it also can become a PR issue for the insurer. Claims of this type can be automated as straight through process by the application of business rules. It is also necessary for this automated process to identify opportunistic fraud.
Other than managing the business rule as the external context changes, very little human intervention is necessary. It allows the client to be directly a part of the organisation process.
The next step is to manage those claims that fall outside the ambit of the straight through process. There are many actors that take part in claims management, the claims adjuster, the legal, the underwriting, external re-insurers, and many more. If the procedural break up is to be made of the process at this stage we require inputs of these actors (expert or knowledge worker). In all complicated process without the need for context the knowledge worker will provide the procedural brake down of the process tasks. The flow of the tasks, that is, the cause and effect will also be part of this break down, although the actual flow for any given instant of the process is up to the knowledge worker at runtime.
- The implementation of complicated processes is based on case management principles.
- A claims process for house damage may involve many actors; one of them is the claims adjuster. It is possible for the adjuster to close the process/case after inspection by offering an immediate settlement. At other times he may involve any one or all of the following actors, the legal department, the mortgage provider, etc.
What has been achieved up to now is that the process under investigation has been approached through the lens of certainty. As long as we are sure of not requiring the context of a specific instance of the process than we can rest easy in our pre-determined procedural break down of the process. Most tools would happily allow for an implementation of such a process design.
Once we get to an uncertain part of the process domain then this procedural break down is not possible anymore. The task to be performed is determined within the context of the process. The history of the process with the outcome of all the tasks up to that point in time, and the availability all information would be needed to decide on the next task. At this point we are creating dynamic tasks to the process history.
- The uncertainty is an inherent part of the process, and not a reflection on the knowledge workers abilities.
How often does one come across situations wherein one fails to complete a business process design due to uncertainty or lack of contextual information in the process? In such situations you are never going to be able pre-determine the task flow; you actually do not know what follows until you see the history of what has passed, and only when you are present in that context. Although, analytical and sense-making methods may get us closer to an understanding of the problem, tools are still far behind in supporting processes that fall in the domain of uncertainty.