A few weeks back there was story about another failed BPM project, this time it is a six-year project costing $300 million dollars in the Social Security Administration, and the reasons, “… a project racked by delays and mismanagement, according to an internal report commissioned by the agency”.
We will never know the true reasons behind the “delays” and “mismanagement”, but perhaps the problem goes deeper. Is it conceivable that such failures may be attributed to our inability to think and analyse problems using the right tools and faculties? The tools we use influence our faculties and vice-versa. Our ability to understand the process under consideration may be affected by the tools we use, and also certain aspects of our faculties that come into play.
As in the experiment of “The Invisible Gorilla” by Christopher Chabris and Daniel Simons, that highlighted the blind spot people developed when intensely focused on a specific task, perhaps our ability to implement BPM also suffers from similar or otherwise unexplained blind spots.
In “Thinking, Fast and Slow”, Kahneman, identifies two modes of thinking specifically “fast” and “slow”, and each of the modes is in turn controlled by a mechanism he calls “System1” and “System2”. “System1” is on autopilot and always active, whilst “System2” is mostly idle, only working when requested to do so by “System1”. “System1” makes quick judgements, and it calls on “System2” for more detailed processing required to solve the problem.
Consider the following two artefacts derived from an analysis of the HR recruitment process. We are only looking at a small part of the whole analysis to keep to the context of our story. Artefact 1 was derived by the application of the DEMO method.
The figure depicts a part of the transactional analysis of the recruitment process. The encircled part in the figure represents a bucket of tasks, which the case owner chooses to decide to execute. There is no pre-determined causal flow; the result of the execution of a specific task will affect the choice of the next task from the bucket by the case owner. The critical assimilation of the information in the figure would require more than just “System1” faculty. It would need a deeper analysis of the content to be read, synthesised, and validated. The facts associated with each transaction would require thought and confirmation from an in depth appreciation of the process.
Contrary to this “analytical” method, we have BPM design tools that provide a drag-and-drop method of designing a process. By themselves these tools encourage a causal way of thinking and until such time as the learning curve has been climbed, they are an excellent way of learning the ins-and-outs of the pictograms. But, they lack in providing the deep understanding of the process required for a successful implementation of the process. The tool encourages fast thinking via “System1” and will only handover to “System2” when the semantics of the tool constructs are in conflict, and not when the process being pictured is at fault. Transferring this knowledge down the team has its own problems; the flow diagram type thinking will affect interpretation and understanding.
Increasing the probability of a successful implementation of a business process needs to be approached by an “analytical” method such as DEMO. The design tool can come into play when this is done, so the focus is on converting the business process into the technology language of the implementation.
NOTE: The terms “System1” and “System2” are merely pointers to certain aspects of the thinking process.