One of my assumptions about Business Process Management (BPM) systems is that they can empowers users. By users I mean task participants—human workers who actually perform the jobs defined by the BPM. These systems orchestrate processes, make them visible to the participants and facilitate collaboration across the enterprise. BPM installations, within the confines of the process defined by SMEs, provide workers with: a choice of the tasks they select from their ‘work queues’, a shared process context so they can see where they fit in to the ‘bigger picture’ and metrics that show how they are performing.
I now understand that, in some cases, this ability to select jobs is the last thing workers or the SMEs really want…
“Just Tell Me What to Do…”
At a recent BPM training session, I got into a discussion with some BPM stalwarts about worker task selection. I learned to my surprise that many workers of BPM systems, those that perform the tasks defined and orchestrated by BPM, actually prefer to be told what to do: they don’t want visibility of the process or choice of which jobs to pick up from the queue – it’s too much responsibility.
Once you’ve logged in, BPM systems can determine your role and permissions and present you with a pretty, priority-ordered list of outstanding tasks—according to the inbound business events, the work of your colleagues and the over-arching process defined by experts. Some BPM systems can be configured to allow users to manipulate and select from this list because, often, ‘human knows best’. This seems to provide a flexible approach. But a sizeable population of workers don’t want this freedom.
Instead they’d like to press a button and be told what to do. Much as some of us might find this prospect demoralizing, these users find the duty of choosing a task too onerous. Any choice gives them the anxiety of making the wrong selection, they are happy to delegate this decision.
Gaming the System
Other participants relish this ability to choose for all the wrong reasons: it allows them to pick (and get credit for) the easy jobs, leaving the burdensome tasks to less savvy colleagues. They tend to ‘game the system’ in order to optimise their own KPIs and performance metrics at the expense of others. Paradoxically, doing this well requires experience of the process, so the difficult tasks will be left to those people with the least experience. These workers will appear to perform poorly and may be replaced, lowering the experience in the worker pool. This is a vicious circle.
Solutions
How do we address this when we design BPM installations? The tempting answer might be to appease the first set of users, and circumnavigate the gamers, by providing a button which says ‘give me the next task’. Provide no selection and no control. But I find this unpalatable and defeatist. It would be better to use analytics to score the difficulty of a task and offer extra credit for workers who take on difficult tasks.
Mine past experience of task complexity to out-game the gamers and provide them with a new and more constructive game to play: can I select a difficult, high-credit task and perform it faster?
The main point was as you quoted : “changes in genuine requirements are slowest, process changes slower and rules changes most frequent”. I also agree the analysis team needs to focus on decision step of the business process which at the implementation point of view will call a decision service using business rules. This was not really the purpose of this post. I’m preparing an example of BPM-BR modeling for the future that should describe this.