USE-CASE: A business process or activity for doing work.
WORKFLOW: How categories of work flow through your business.
Categories of work? What the heck does that mean? When I think about workflow I often catch myself imagining that I was personally executing the business and going from node to node to node along the workflow. That is wrong. It’s not what a workflow represents. We should be thinking about workflows from the perspective of the work, not the people or automation (robots, nightly jobs, scripts, jobs, triggers etc) that perform the work. That’s how a “workflow” is executed.
Allow me to show what workflow is by analogy. Supposed that my business is to process a piece of metal. Doesn’t matter what it does. Suppose that we specialize in treating the metal and that pieces of metal are delivered to our factory on 1st street and they exit to the loading dock on 2nd street after having gone through our “workflow.” Our story begins in our fictitious warehouse on 1st street.
The warehouse/factory has stations all over the place. Each of the stations does a particular piece of work, usually on the piece of metal. Sometimes the stations just do analysis, perhaps analyzing the results of an x-ray or other test done on one of the pieces. Sometimes the analysis is just financial, capturing the effort and materials for a particular treatment.
Work generally begins when a piece of metal arrives at a station. There is an x-ray station. There is an audio analysis station that checks for resonate frequencies. There’s a surface treatment station. A priming station. A painting station. A station that laser etches the surface. There’s a stamping station that creates a physical label with critical information like serial number, etc. There is a tensile station that measures the physical properties of the metal piece.
There are some physical limitations to the order in which our work can be done. For example, you want to stamp pieces (if the customer requires stamping) before it is painted (if the customer requires painting) or the paint will be damaged.
Each station receives an item into it’s work queue. If the item is a metal piece then the function of a station is performed on exactly that 1 piece of metal. The station can immediately go again and process another item from the work queue, but the stations work is done once for each piece of metal. The station’s work process is executed once for each piece of metal. Similarly the analysis and financial stations perform their work on their work items one at a time.
Back in the old days (6 months ago) the metal came into the warehouse and began it’s workflow by going to station 1, then station 7 then station 3 then station 6 and so on. But 6 months ago it was decided that going station 3 then 1, 7, and then 6 was a better workflow.
There are employees or robots at each of our stations. Whether it’s a robot or an employee they begin the work (the processes, the activity, aka: the use-case) of their station by taking the next piece of metal from the queue and performing the use-case of that station against the piece of metal. While some of our staff are trained to work at multiple stations they generally don’t move around. They can switch stations if someone else is absent. The robots are also programmed to perform a particular use-case at a particular station. We can reprogram the robots if needed for the use-case of another robotic station, but day to day a robot stays at the same station and performs the same use-case.
What flows between the stations is the work. To enter the queue at a station the piece must have been processed by the stations which are earlier in the workflow. Many of our stations have ways of testing whether a piece of metal has come from another work station and had that use-case executed against it. This testing/confirmation is also used to spot defects and to exclude problem pieces from continuing to flow through the work.
You can think of the pieces of metals as items. What flows between the stations are the items to be worked on. The work-items.
I’ve seen other businesses like the inventory warehouse across the street. Their work flows as part of fulfilling orders. When an order arrives at the warehouse the work flows through their warehouse. They use the order to create work items for each of their stations as different documents. An order becomes a packing list for the inventory/picking station, a shipping manifest for boxing station, an invoice over at the accounting station, etc. Each of these work items flows between the stations just like our work items and there are checks and tests in place to ensure the success of these use-cases.
When documenting a workflow it’s important to think about what are the work items and how do those work items flow between the use-cases that operate on them.
This week a colleague and I have been working on a problem for his work. I asked him to create a workflow diagram. He diagrammed (quite understandably) the various processes to perform the work. His excellent diagram even included the work of other actors. There was a section involving the resolution of a decision impasse, a tasks my colleague can’t perform. I tried to explain that the diagram wasn’t quite right but I wasn’t able to verbalize why.
At about this same time someone else asked about a thing he’s working on using CRUD. Where did the CRUD operations fit within the workflow. That question was easier because CRUD is just never part of a METHOD solution. It’s never part of the workflow. The lowest level “thing” in the METHOD is an atomic business verb. ABVs are never CRUD.
What both were attempting to do was describe the process(es) from the perspective of a user. But in the story I’ve told above I’ve tried to make it really clear. You create a workflow from the perspective of the work, not the user. The user is there to perform the work.
I hope that helps.
