In the 3 years since publication of my book "Human Interactions - the Heart and Soul of Business Process Management", reactions from BPM specialists have been mixed.
One frequent response is: "at last someone is saying what I've always thought". In other words, the mixture of consultancy observations and insights from varied disciplines that is Human Interaction Management (HIM) seems like simple common sense.
Another frequent response is "that can't be right". In other words, please don't let this be right - because if it is, we've got to start again, almost from scratch. Both consultants and software vendors are going to have to make dramatic changes to the solutions they are offering.
Current BPM solutions (both method and theory) relegate human collaboration to the fringes of organizational life, treating as an backwater of unmanageable "ad-hoc" work where "here be dragons". This is not good enough, is it. Organizations need knowledge workers to be:
- More efficient - work faster and leave tidy information behind. Basex estimate that 28% of knowledge worker time is lost to poor control of interactions. So we need better teams, better communication channels, better generation of knowledge from information, better time management, and better planning tools (these are the 5 HIM principles, by the way). How are current BPM and case management solutions going to give us any of these? To the worker, "human-centric" software offerings are still just task lists, with the added complication that they are now expected to create their own tasks.
- More effective - adapt their work to changing objectives. The key word is "changing". It is not enough to allow people to plan their own activities in ad-hoc fashion - this is just a gateway to chaos, in which people go off at tangents the whole time, leaving behind a sea of unstructured audit trails. Human work needs to be part of a management framework geared around driving top-down change (i.e., from current strategy) while empowering bottom-up decision-making (i.e., allowing people to negotiate next steps in a structured way as they go through a process).
In this blog series, I am relating these needs specifically to BPMN, by showing how BPMN notation cannot express constructs that are critical to the efficient and effective management of human work - while HIM notation can do so easily. Here is another example.
In the HIM diagrams featured in previous posts in this series, you will notice that each Role (yellow rectangle) has the word INSTANCE underneath its name. This means that the Role is active in the process - it represents a real, working participant. Some Roles, however, are used differently. Here is another version of the HIM solution to Respond to RFP from a few posts back, again generated using the free HumanEdj:
Notice that this time the Technical Consultant Role is shown as a TYPE rather than an instance. Also, the Account Manager has a new Activity, to assign a Technical Consultant. What is going on?
The new diagram reflects the fact that, in some cases, the Salesperson will not need technical consultancy - they will be familiar enough with the solution to be offered to the client that they can prepare the proposal unaided. In the new version, the Salesperson and Account Manager can discuss this via the Initiate Submit Proposal Interaction - and depending on the outcome of that discussion, the Account Manager may or may not create an "instance" of the Technical Consultant Role "type".
How would this be depicted in BPMN? You would have to create a swimlane for the Technical Consultancy work, and make all its activities optional in the process. In other words, work has been assigned but may never happen. Further, there is no explicit depiction of how the work will be assigned - under what circumstances, when, who by, to whom, the sort of skills and experience required, and so on. Critical aspects of human resource planning are omitted from the process - of necessity, since there is nowhere to put them.
TAKE AWAY
To remedy process description deficiencies such as those described in this blog series, software vendors typically advocate the use of business rules in conjunction with process execution software based on BPMN and/or XPDL.
While one of the 6 key HIMS object types is a Rule, which can be applied in many ways, Rules alone are not the answer, since in large quantities they are unmaintainable. For routine work, we are moving toward an agent-based approach in which rules are key - when you run a process a million times, the effort of maintaining the rules is worth it. But for human-driven work, in which every process instance is different, there is no value-add in burdening it with huge numbers of rules. Not only does it constrain the work artificially (just ask a doctor whether they would let a system diagnose for them), but there is zero motivation for the people involved to help maintain the rules, since they are only putting themselves out of a job - so people will work around the rules and let them degrade. I've seen this in many organizations over the years.
The key issue is that human-driven work is fundamentally different to routine work, for a variety of reasons ranging from socio-economic issues such as globalization (in particular, the availability of very cheap workers) to psychological issues such as team building (as Handy predicted 20 years ago, corporations are becoming virtual). Organizations ignore this at their peril! As Jon Pyke, Chair of the Workflow Management Coalition, wrote in an article on this site in 2006:
Process-based technology that understands the needs of people and supports the inherent "spontaneity" of the human mind is the next logical step, and we might be tempted to name this potential paradigm shift "Knowledge Intensive Business Processes."
KIBPM falls into two main categories, which will probably merge over time, and the vendor that recognizes that potential will steal a march on the others. At the simplest level we have case management, and secondly, we have Human Interaction Management. I doubt there are many BPM products on the market today which will be able to meet this seismic shift in requirements - certainly those that rely on BPEL and SOA won't; what's more, any that have been in the market for longer than five years will need radical surgery to meet the coming challenge.
Why Workflow Sucks
In other words, radical new ideas and accompanying new technology are required, that go way beyond case management. So why have the major software vendors stuck with the kind of workflow and state-based case management solutions that have been available for years? Well, all suite vendors have a huge code base to maintain, and it's easier to tinker with what they've got than to develop new code from scratch. But this isn't serving the market, or ultimately, themselves.
To thrive in the next 50 years, we need new insights, new practices and (ultimately) new forms of software.
Leave a comment