In response a previous blog entry, Gerald Loeffler raised a question about the potential relationship of Naked Objects to workflow or business process management (BPM).
I have always disliked both of those concepts for three reasons. The first is from technical perspective: they tend to encourage the separation of procedure from data and thus discourage good object-oriented design. The second is from a human perspectice: workflow and BPM systems tend to encourage a management philosophy that disempowers the users. I wrote about this in the original Naked Objects book back in 2002 and subsequently in my thesis. The third reason is that workflow, as generally conceived, simply doesn’t work!
Recently I met with a workflow expert who works for one of the major systems integrators; to my susprise and delight he concurred with my assessment. He told me that in a very high proportion of systems that they install, the workflow element is completely switched off within a few months of the system going live. I asked him why his company continued to build workflow into new systems and he told me that it was invariably because the client’s management insisted upon it. What I mean by ’as generally conceived’ is building explicit representations of complex business processes or flows of work, and then running these scripts on some kind of engine that drives the tasks that individual users perform. This idea appeals hugely to management for two reasons: it allows the script to easily edited as the business organisation changes; and it gives the management better control and information about what is going on. In theory, that is. In practice this breaks down because real business processes are seldom capable of being 100% scripted, and as soon as you allow any kind of non-scripted variants the whole system breaks down. In The Social Life of Information (an excellent book), John Seeley Brown points out that the most valuable people in an organisation are those who’ve worked out how to get the job done for the customer, by overcoming the constraints of the formal business processes. However, I believe that there is a legitimate role for work assignment. Indeed I have designed several Naked Objects applications that involve a Task object. When the user logs on, they are presented with a ‘work list’ or ‘task list’. Each Task typically has a TaskType, a longer description and/or instructions, and, optionally, a Task Subject – the domain object (such as a Customer or Order), if one exists, that would be the starting point for the user to perform the task. Tasks may be assigned to an individual user or a team, and they may be transferred from one user or team to another. When the user has completed the task, they invoke the ‘Completed’ action on that Task, which records the date/time of completion, possibly one or more ‘completion options’ to record how it was completed, and then removes the Task from the worklist.
Sounds like worklow! So how does this differ from the approach I have just criticised? The distinction lies in what generates the Task. In the systems I have designed Tasks may only be generated by:
1. An explicit externally-generated event, such as the receipt of an email, or the scanning of an incoming paper document. The system can use this to generate a Task to deal with that event, and assign it to the appropriate team or individual – either based on a generic rule or on, say, the bar-coding on a scanned form. This, very limited, form of work assignment is indisputably an aid to productivity.
2. A user may generate a Task if they identify the need for an action that they cannot fulfill themselves there and then. In other words they can create a Task and assign it to a colleague, in which case the Task is acting rather like a structured email. Or they can create a Task to prompt themselves at a future point: e.g. bring [this object] back to my attention in 21 days, if nothing else has happened on it.
What these two design principles explicitly disallow is the idea that upon completing Task A, the workflow engine regains control and then issues Task B, either to the same user or another: the conventional notion of workflow. Rather, these two design principles reflect the fact that real business processes reside in the heads of the staff, and that is the best place for them.
So how do you stop things from falling between the cracks i.e. the user completes the first Task and then doesn’t continue to process a particular case? If this is a concern (and it need not necessarily be) one option is that all ‘purposeful’ objects (such as Case, or Order, or Enquiry) will have a status, such as ‘Active’ or ‘Completed’. It is a simple matter to run a periodic exception report, looking for all purposeful objects that have an active status (i.e. they should be being processed) and that do not currently have an associated Task that is assigned to someone, or have not had one for, say 24 hours. These can then be brought to a manager’s attention. Alternatively, the system could automatically send a reminder to the last person who marked a Task on that object as completed, asking them why they did not either create another Task, or move the purposeful object itself to a completed status. In my experience these situations do arise when the system is first used, but quickly die down once users get comfortable with the system.
I understand that all of this is a somewhat controversial view of business, but it is based on real experience. It reflects a very strong personal viewpoint that, to the extent that an information system involves human users, then the system should be designed to be the servant of the user, not the master. Most workflow systems attempt to be the master of the user.