A workflow can be described as a repeatable co-ordination of activities that affect an identified piece of work (work item), across multiple roles and governed by business rules, beginning with the generation of the work item and ending with the resolution of the work item.
I am quite specific in my use of language in this definition.
I say “co-ordination” rather than sequence, because a workflow is not necessarily a linear sequence. Sometimes the flow can split and be assigned to more than one role at the same time.
I make specific reference to activities that affect the work object because activities that do not affect the work object, however closely related they might be to the overall business process, do not form part of our workflow.
Notice that I say “multiple roles”. If there was only one role, although work is being done, it is not flowing from one role to another, thus the notion of workflow involves more than one role.
Finally, I say “resolution” rather than completion. This is simply because completion is not the only possible outcome: cancellation and rejection by an reviewing authority are other possible outcomes.
This is only one possible definition, of course, and you will find other valid, but similar definitions.
When analysing workflows, I have found it is best to imagine the work being done on paper, that way you won’t risk thinking in terms of the IT implementation. In this series of posts I will be drawing a workflow in such a way that it is not restricted to any particular form of implementation (it could be implemented using sticky notes, e-mail or workflow software, for example).
Production of workflow diagrams is part of low level requirements analysis. However, the need for a workflow should already have been stated in the high level system requirements (i.e., the project scope) and there should be further of high level statements to support that.
The case of our workflow, the project scope would include statements along the lines of the following:
- The System will provide a workflow for handling leave requests
- Employees will be able to submit leave requests
- Line managers will be able to review leave requests
- Human resource managers will be able to review leave requests
- Employees will be able to review rejected leave requests
Of course, in order to draw a workflow, we must first identify the work object in question. If the high level statements of requirement are adequately written, it will be obvious what the work object should be. In this case it is a leave request.
The statements above would provide sufficient scope for low level requirements analysis of the workflow. The last four statements are worded in such a way that they could be investigated either as use cases or as user stories. This is an important point: the high level statements of requirement should not impose or suggest a particular methodology.
Just a quick word on choice of words: notice that I said “review” above, rather than “approve”. The latter is often used in workflows because requests have to be approved in order to proceed. However, in reality, rejection is a possible outcome and to me it does not make sense linguistically that one possible outcome of an approval is a rejection. The activity is a review, which can have more than one outcome (even though approval is expected to be the norm). You might consider this a little pedantic, but the idea is to remove as much ambiguity as possible. After all, we don’t want a particularly inflexible analyst in later workshops telling the customer they cannot have a rejection scenario because the scope document only mentioned approval.
In Step 1, we shall start to draw our workflow.
If you want to see only the posts in this series, select the category “Drawing Workflows“.
Leave a Reply