Determining Current Work Processes

Defining the system scope is actually the first step in analyzing business processes, since the definition will tell you the processes you need to analyze. The order in which you examine the various processes within the system's scope is usually unimportant. Even if you're planning on implementing some system components prior to others (incremental development), you should perform at least a cursory analysis of all the work processes the system is going to support before you begin implementation. Doing this allows you to find any dependencies between processes that might affect the order in which components must be implemented.

Speaking to Users

Having identified the work processes that are within the scope of the system, your next task is to capture everything that is currently done in order to carry them out. You needn't worry overmuch at this point about what represents a task and what is, perhaps, a separate work process that requires further analysis. Just find someone who can tell you, "Well, we get this document from the sales person, and first we just look through it to see if they've completed it correctly; if they have, well, then we pull the customer file, and…" Ask lots of questions, and write it all down. You should also get copies of any forms or reports that are either used as input during the process or produced during it. Your goal is to understand what happens; you're not yet analyzing the process.

By the way, many people refer to this phase of the analysis as "user interviews." I prefer "discussions" or some other neutral term. It's easy to underestimate how intimidating computers can be, even to people who currently use them. Lots of people still worry that they're going to be replaced by a computer, and "user interview" can easily be mistaken to mean, "We're going to decide who gets the sack." This is particularly true in large organizations in which it's not usually possible to speak to everyone, and many people might be unsure exactly who you are or what you're supposed to be doing.

Whenever possible (and it isn't always), you should try speak to the individuals who actually perform the process rather than to a manager or supervisor. My experience has been that managers tend to have a rather ideal view of the work processes under their jurisdiction. The person who performs an activity on a daily basis is in the best position to tell you the problems and interruptions he or she faces. Of course, you should speak to supervisors as well, since they often have the best understanding of why specific tasks are performed and the ramifications of not performing them or performing them incorrectly.

During your discussions, be sure to look for any possible exceptions to the process. If the user says, "We check the order for completeness," for example, be sure that you know what happens if it isn't complete. Chances are that they just bounce it, but you need to know whether they try to find the information themselves; perhaps your system can make the process easier. In fact, for every activity that a user performs, you should ask what can go wrong and what happens when it does.

Since we're specifically interested in database systems here, you should also pay particular attention to how data is getting used during the process. What bits of information are being used? Where do they come from? What form do they take? What happens if they're not present or not in the correct form? The answers will form raw material for the conceptual data model we'll discuss in the next chapter.

Many work processes consist of tasks that are performed by different individuals. Obviously, you should speak to all the people involved whenever that's possible. This recommendation also applies to people whose tasks are ostensibly outside the scope of the system. Take, for example, the sales order process described earlier. The "Ship order" task might in fact be "Send order to the Shipping department," and what happens to it in the Shipping department might be outside the scope of your system. It's still a good idea to talk to people from Shipping to confirm that they're getting all the information they need and getting it in a form that's useful to them.

Similarly, if a report gets printed at any point in the process, you should find the person who receives the report and learn what he or she does with it. You'll be amazed at how many pieces of paper on average get passed around an organization for no apparent reason. (Then again, maybe you won't.) Or, as is more often the case, there is a reason for the report but it contains the wrong information, or it contains the right information but in the wrong format, so it's being neatly filed somewhere and is not being put to the use for which it was designed.

Identifying Tasks

After you've talked to the people who are currently performing the work your system is going to support, you should have a reasonable understanding of the activities involved. Your next step is to organize this information into a set of tasks. The key is identifying the business rules that apply to the process.

At the beginning of the chapter, I defined the term "task" as a discrete action. It's now possible to define more precisely what "discrete" means in this context. It means two things: that the action has an identifiable beginning and ending, and that all the pertinent business rules are valid before the task has begun and after it is completed. The rules might be temporarily broken, however, while performing the task.

A business rule is nothing more than a constraint that originates in the problem domain, as opposed to constraints that derive from, for example, a data type. Thus "No orders can have a ship date of April 36" is not a business rule, since it's dependent on the domain of dates. (And it's a pretty silly rule, anyway.) But "No orders can have a ship date prior to the order date" is dependent on the problem domain; it is a function of the way the organization does business. Thus it is, or at least could be, a valid business rule. The term "business rule" is used, by the way, even when the organization isn't technically a business. The database you're building to track your collection of antique thimbles is still subject to business rules.

The vast majority of business rules relate to the way data is handled. "Customer zip code cannot be empty" and "Invoice date must be on or after ship date" are examples of data-related business rules. Other rules, such as "Sales manager authorization is required when orders will cause customers to exceed their credit limit," do not directly constrain a data value, although they might be triggered by a data value as this one is.

Don't worry; finding the business rules that pertain to a work process isn't as difficult as it might sound. This is what all those "How can this go wrong, and what happens if something does?" questions were about. You don't need to worry too much at this point about what the details of the rules are. The details are part of building the conceptual data model, which you'll do later. All you need to do here is group the various activities you've identified in such a way that you're reasonably confident the business rules can be valid on either side of the action.

Let's look at an example. Say your list of actions for processing a sales order includes the following tasks:

1. Check sales order for completeness.
2. Retrieve customer file if existing customer.
3. Record shipping information.
4. Enter order details.
5. Assign customer number for new customer.
6. Check item availability.
7. Check customer credit limit.
8. Pick order.
9. Pack items.
10. Prepare shipping documents.

The first thing to notice about the list is that things seem to be done in a somewhat random order. That's OK. You're only trying to understand how things are currently done. Cleaning up the process happens later. Some of the items also seem to contain a different level of detail. We'll look at that in a minute. For now, let's just identify the tasks.

Item 1, "Check sales order for completeness," has a discrete beginning and ending. The action takes place when a new order is received, and it is completed when the entire document has been checked. We can assume that all the business rules are valid at the beginning of a process, so there's no problem there. If the initial sales order document doesn't comply with the business rules, it will be rejected. So we know that if the process continues to the next step, the rules will be valid. So item 1 qualifies as a task.

The only business rule that pertains to item 2, "Retrieve customer file," is that the individual retrieving the file must have access to it. We'll assume that anyone performing this process has access to the files, so that task criterion doesn't apply. The action begins when the sales order has been checked, but since the file is used during later actions, it doesn't have a discrete end point. So it's not a task; it's one of the steps within a task.

In fact, the customer file is used in item 3 ("Record shipping information") and item 5 ("Assign customer number"), which is the first clue that these items belong to the same task. Indeed, it's clear that items 2 through 5 can be grouped together into a single task, called perhaps "Record order." In this case, item 4, "Enter order details," is clearly a part of recording the order. Don't be surprised, however, to find that some tasks are performed simultaneously. In a manual system, it's easy for someone to be filling out two forms at the same time. The fact that the forms logically belong to separate tasks doesn't matter.

We now have a new task consisting of four discrete steps. It begins when the original document has been checked for completeness, and it ends when the entire order has been recorded. But there's a problem. Your client doesn't allow customers to place orders that exceed their credit limit, but the credit limit isn't checked until item 7, "Check customer credit limit," after the user has checked that the ordered items are available. Until the order is confirmed to be within the customer's credit limit, however, you can't be certain that the business rules are valid on either side of the task. So item 7 is part of the "Record order" task.

Item 6, "Check item availability," isn't logically part of recording the order, however. In fact, item 6 represents a discrete task that begins once the "Record order" task has been completed and ends upon confirmation that there is sufficient stock to ship. So item 6 is a task on its own. Don't say I didn't warn you.

In situations like this, be sure to find out why the tasks appear to be done out of order. It's most often simply a matter of convenience, but occasionally these inconsistencies result from some operational constraints that can have an impact on your system processes.

In this instance, if the item availability is checked first simply because that's logistically an easier check to make, you can rearrange the activities. But you might discover some interaction between the order entry process and the production process that requires stock levels to be checked immediately, and this interaction would have to be accommodated in your system.

Notice that it's not necessary to specify in detail the business rules that apply to a task. You do need to be reasonably sure that the rules, whatever they might be, will be valid. In this case, we can assume the order will be rejected if it doesn't comply with all the relevant rules, so we needn't examine them in greater detail at this point.

If we were to discover later that an order shouldn't be accepted unless there is sufficient stock to fill it, the "Check item availability" task would become a step in the "Record order" task. As we'll see in the next section, moving activities around between tasks and between logical levels is a fairly simple process. The crucial issue here is to identify the activities.

Analyzing the next three items on the list—8, 9, and 10—depends on the scope of the system. If shipping of products is part of the system to be developed, these items need to be looked at carefully. If, as is more likely the case, the scope of the system ends when the completed order is passed to the Shipping department, these items can simply be lumped under a single task, "Submit order."

We happen to know, of course, that several things will occur after this point, and there's no reason to throw that information away. From inspection, it's clear that each of these remaining items are tasks themselves. In fact, the final item on the list, "Prepare shipping documents," might even be an entire work process. But all of those tasks lie outside the scope of the project, so we'll list them as steps to preserve what we know but we won't otherwise concern ourselves with them. Our revised task list is shown below:

Task 1: Check sales order for completeness

Task 2: Record order

Step 1: Retrieve customer file

Step 2: Record shipping information

Step 3: Enter order details

Step 4: Assign customer number

Step 5: Check customer credit limit

Task 3: Check item availability

Task 4: Submit order to Shipping department

Step 1: Pick order

Step 2: Pack items

Step 3: Prepare shipping documents

During the process of organizing activities into tasks and processes, you will almost certainly discover things that you don't understand as well as you thought, in which case you should go back to the users for clarification. In any case, you should review the processes with the users. Often, seeing the process written down will prompt them to provide additional information—steps they've missed or exceptions that you forgot to ask about.