Award Sounds

Introduction

Processes can be broken down into more detailed processes. In this article, I'll take one of the process steps from the previous article and look in more detail about how it connects to the other components of the process.

Some Perspective

A key feature of any workflow system is that you should be able to look at the system from different levels, e.g. a director's view of the system may only show 5 or so process steps and cover what it takes 10-200 people or more to perform. A user's workflow will probably require several process maps, each relating to the different processes that they perform on a daily basis and some that are less frequent. The solution's workflow could feature many process maps, perhaps describing the user interfaces and the core system's interfaces with external solutions.

Each map communicates to its intended audience. That means that we, as analysts, have to write for that audience. Fortunately they all follow the same basic principles. They should all relate to each other, if they don't, then there's a gap that needs to be addressed.

Using the 3 levels above, we should be able to look at the director's level process model and delve into the process steps. Say we look at the process step 1 in that model, we should be able to find a user-level process model that shows us the detail of that step. Similary when looking at the user-level process model, we should be able to look any process step and see more detail in the process described in the solution workflow.


So how do the processes fit together?

The first point to understand is that most process steps can be a processes in their own right, usually with more detail. Rather than have all that detail on every diagram, it's more common to display a box for the process step and that refers to a more detailed process map for that step.

Let's take the Buy a Book process from the previous example and work through that.



The Pay For Book process step includes a number of its own steps when it's viewed as a process. We'll take a very simple concept of paying by cash. The same principles apply to paying by credit card, just that there's more involved in that process.


Like all of these processes, real-life is more complex. For instance, scanning the book would display the price on the till. There's also more happening with process cash payment, e.g. what about giving change back? I've changed to yellow just so it's easier to show the different levels in the following diagram.

The glue is the Process Start and Process End points. These connect to other processes.

Note the name of the Process Start? It's the same text as the process step in the original Buy A Book process. When reading Buy a Book, you may want more detail about Pay for Book, so look for the process model entitled Pay For Book and it should have one Process Start with the same name. The End point again assumes that the process has been completed. If we were looking at more detail, it could be that the buyer couldn't pay and so didn't purchase a book. For the moment, we'll leave that outcome.



If you look at the Pay for Book process-step in the top row of the above image, you'll notice I've included a small image of the Pay for Book process. The use of colours is just to help me show how the processes fit together here. It's incredibly rare to have the process and the more detailed process on the same page. In fact, I can't ever remember doing that apart from when I'm showing the relationships between processes in articles such as this one.

I mentioned that the Process Starts and Process Ends are the glue because the detailed process (the lower one in the above diagram) should be able to fit into the main process (the upper one in the above diagram). It should do this without overlapping into any other process steps. Choose Book will also have its own detailed process map.

Here's an incorrect example highlighting Choose Book and Pay For Book.




That Choose Book process relates to the Choose Book process step. Actually, maybe I should state that the Choose Book process is the Choose Book process step. It's the same thing, just different views of it. One view shows more detail than the other. 

In the above diagram, I've put two crosses, not part of any standard. I've used them to highlight what's wrong with the Choose Book process as depicted above. The second of the crosses is easiest to explain.

The process step of Scan Book more properly belongs in the Pay for Book process. We can see it in the Pay For Book process, so let's keep it there. If it's also in the Choose Book process, then we're duplicating actions. Someone following the overall process in the diagram above would end up scanning books twice. That's not right.