From time to time we are approached by prospects requesting task control automation by BPM.
The idea is simple: someone assigns tasks by setting goals, responsibles and terms. It’s easy enough to develop a system automating terms control, due dates reminders, statistical analysis, etc.
Any decent process system (i.e. BPMS) features built-in task management. Task durations, notifications, delegation, on-the-fly reassignment in the event of unplanned leave are available out of the box. If necessary, the process scheme can implement more sophisticated things like timers, escalation or cancellation by external events.
But there are two problems.
1. Who assigns the task?
The core problem isn’t the control over task execution but mutual agreement on who should do what in what sequence. Different departments are not in position to make orders to each other. Department A may believe that it assigned a task to department B but it does not automatically mean that the department B accepted the task for execution.
Hence such assignation should me made (or at least approved) by the “big boss.” But the big boss is a valuable resource so using it for task assignation within routine yet critical business processes such as quotation or sale is terribly ineffective.
Let’s comparable with process management: it’s not the automation, it starts with the willingness of participants to agree about who, what, in what order should perform in the best interests of the client. The major performance issues typically occur not within department boundaries but between them.
The paradigm of task management does not consider who, how, on the basis of what rules assigns tasks, it’s beyond the scope. Yet any process practician knows that setting up task assignation rules (i.e. process scheme) is far more difficult than automate task execution control.
2. Where is the context?
Processes (and tasks) aren’t executed in a vacuum. It’s good to know that the task is assigned yet it’s not enough. The task performer also needs the input information which was typically gathered on the previous steps - the process context. The result of the task isn’t just the checkbox “Completed” - it’s the output information and/or decisions made. Process systems provide such context - each process instance has a set of attributes, and each task is associated with certain attributes as its input and output.
Basic task management system doesn’t care about the context; all it provides is informal text description of the task.
More advance approach links a task to a dedicated folder containing Word and/or Excel documents i.e. by utilizing ECM. But if we don’t store the information in a structured way (not in the database) then we should a) be prepared for errors, duplicates and inconsistencies in the data; forget about the integration with legacy systems (e.g., accounting) - multiple data entry, multiple errors.
That’s why when I hear “task management business process” I wish I had a gun.
Not processes alone
It isn’t always doable or practicable to consider our activities as processes. If it’s unpredictable or non-repeatable then we should better switch to the project management or to the case management.
Project management in the context of this post is the task management plus a sequence of tasks plus the power given to the project manager to resolve cross-functional issues.
This is progress of course comparing to the basic task management - now it isn’t the big boss who gives the orders but the project manager. Yet the project manager is also a valuable resource, although not as valuable as the big boss. There is no choice when we deal with the unpredictable activities but when it comes to routine processes, the use of qualified personnel with managerial abilities and skills as a process engine is the obvious waste.
Besides, the typical project management doesn’t provide the context: “Completed” checkboxes are managed by the project system while the data is spread among applications if not paper sheets.
The case management systems (ACM) are good in providing the context but their ability to cope with cross-functional issues is questionable. The same issue may arise: department A may assign a task to an employee of department B within the case C but are we sure the latter would accept it readily? It’s no surprise that most case management examples don’t go beyond a single department.
However it doesn’t seem to be a tough problem, the key is to combine the technological capabilities of ACM systems with methodological techniques of the project management - the case responsibility should be assigned to a project manager with adequate power, the case meeting should be performed on the regular basis, etc.