Designing Relational Database Systems (Dv-Mps Designing)

Now that you have a clear idea of how things are currently done, it's appropriate to examine the work processes for possible improvements. As I said earlier, most organizations have a great deal of inertia. This applies equally well to processes as to working with documents. The deployment of a new computer system provides an excellent opportunity to clean up some of the dead wood.

There's an old efficiency rule that says you should never handle a piece of paper more than once. Like many rules, this one isn't always practical, but it's not unusual to discover that a work process can be simplified by reordering the tasks so that bits of work aren't traded back and forth between individuals or processes. For some reason, this sort of "I do A and give it to you, then you do B and give it back to me, then I do C" process is difficult to see when you're involved in the actual work but is immediately apparent when the activities are written down.

To do this kind of analysis, you must be very clear about the task dependencies. Within any given process, some tasks are dependent on others and must be completed in a specific order. You couldn't, for example, transmit the order to Shipping before you record it. The order of other tasks can be reasonably independent. It doesn't matter greatly, for example, if you assign the customer number before or after recording the shipping details.

It's particularly important to look at data dependencies. Some tasks are responsible for creating information, such as customer numbers, that is used by other tasks. One client of mine, for example, used a sales order process similar to the one outlined in the previous section, except that the Accounting department established the customer number and initial credit limit rather than the Sales department, which was responsible for order processing.

The client's initial work process looked like this:

Task 1: Check sales order for completeness

Task 2: Record order

Task 3: Perform customer credit check

Task 4: Complete order

Task 3 was performed by the Accounting department, which returned the order to the Sales department only if the results of the credit check were acceptable. The problem with this, of course, was that the initial data entry had already been performed. Not only did this mean the work was wasted if the customer wasn't approved, it also meant extra work, since the dead orders had to be periodically removed. It also involved the data entry personnel in arguments between the Accounting department and the sales people, who wanted their orders filled (and their commissions paid). Changing the order of the tasks so that the credit check was performed before the order was given to the data entry people eliminated the inefficiency and hassle.

In addition to confirming the dependencies between tasks, you should check for tasks that no longer need to be performed. These are rarely obvious, but sometimes if you trace the data through the process you find items that are being created for use in another task or process that no longer needs them. It is less likely that whole tasks, or even steps within tasks, are unnecessary. Most people are pretty smart about avoiding busy work, but the situation can be masked by the interaction between processes. The production of unnecessary reports is the most common example of this.

This is not, of course, a justification for making wholesale changes to your client's business practices. Nor would I recommend telling your great aunt Gertrude that she should change the way she organizes the knitting patterns she's asked you to computerize. And, in fact, it is rare to find major inefficiencies in work processes. But your job is to help your clients do their job better where you can, and reviewing the work processes is a part of that.

Related

Категории