Introducing Workflow

Workflow generally refers to the way a business process functions, such as approval for payment of expenses. What is workflow in the context of applications development? Simply put, it is the means by which a business process is automated. In a paper-based office, approval for payment of expenses usually starts with an employee filling out a form to list the expenses ”dates, amounts, and justifications. This paper is then routed to the employee's manager, who signs it and sends it to accounts payable for reimbursement to the employee. Of course, this example is a very simplistic process and, in practice, there can be several levels of approval. Why automate such a process? There are a number of good reasons.

Understanding the Problem

First, take a look at a more complex business process. One with which you are most likely to be familiar is software development. With any significant software application, many changes can accumulate over time. As you know, managing those changes can be more challenging than making the changes themselves ! Requests for changes can come from many sources: from the users of the application to senior management. The reasons for change requests are just as varied; a request for a change might be as simple as a new view or report, or it could be a result of a strategic change in the company's business strategy. Likewise, the scope of the change could potentially affect many people across many departments. To manage such changes, an approval process is often put in place that will enable all those affected to review and approve or deny the request. This can result in a multitiered approval process that can be cumbersome to manage.

Using a paper-based process can break down in multiple ways. Perhaps a change affects five departments, and in each of the five departments, one or more individuals are appointed to review change requests for impacts on their department. The individual who creates the change request must distribute the paper change request form to all reviewers ”after determining who those reviewers are. When the reviewers have a chance to look at the request, they can forward their comments to yet another group of individuals. Perhaps a meeting is scheduled and a discussion of the change request takes place before it is forwarded on to the next level of review. There is really no easy way to keep tabs on this process because it is entirely manual; if a reviewer isn't timely in her review, the whole process can drag on indefinitely. The length of time from the initiation of the change request to its final disposition is referred to as cycle time. Ultimately, each request and its associated documents wind up in filing cabinets , necessitating a physical search if they need to be reviewed sometime in the future.

This example illustrates two fundamental problems with paper-based processes. First, it is anybody's guess just how long the cycle time might be for any given request. Second, there is no easy way to keep track of the status of the request, which is similar to the problems outlined with the send model. Automating this process can help solve these two difficulties. First, the cycle time can be compressed by electronically routing the documents via email notifications. Second, because the requests are documents in a database, the status of the document can be displayed and accessed by anyone who is interested and has access to the database. No longer will you have to rifle through folders in file cabinets to research a request because there is an electronic record in a fully searchable database. These are some of the principal arguments for automating business processes with database applications.

Solving the Problem with Automation

The methods by which business processes are automated using Notes and Domino typically involve email notifications. Sometimes a document will be routed in its entirety, but most often, a link to the document is emailed. Notifications are of two general types: either a newsletter that broadcasts a list of documents or a notification of a single document that needs to be acted on. Very often, these two techniques are combined in an application. In the change request example described in the previous paragraphs, email notifications containing a document link to a single new change request can be created and emailed to the reviewers after the document is saved. The process administrator can receive a newsletter containing a list of document links to requests that have past-due reviews. Email notifications can be created using all the languages available to you as a developer: the Formula language, LotusScript, or Java. The remainder of this chapter covers the methods of sending mail notifications, from simple mail-enabling at the form level to using the scripting languages to mail-enable an application.

Example: Automating a Business Process

A high-tech engineering firm had a process that was paper-based and quite tedious , involving what were called engineering change requests. These requests could be originated by anyone in the company and could involve a better part design or a better manufacturing process. After the change request was approved, it became a change order and new engineering drawings and specifications were made.

The problem with the paper-based solution revolved around the approval process. First, the administrator had to determine who owned the process that was affected and then determine who was assigned to review the process. The change request was then photocopied and stuffed into the process owner's mailbox. The process owner then reviewed it and released it for review, but first it went back to the administrator, who had to photocopy the document with the process owner's comments and distribute it to all the reviewers' mailboxes. Technically, the reviewers had 24 hours to respond, and the administrator had the responsibility of ensuring that they did indeed respond. This often involved multiple phone calls; the actual cycle time of this process was usually quite lengthy. When all reviewers had responded, a meeting was optionally scheduled. If the change request met everyone's approval, it was turned into a change order, which necessitated ”you guessed it ”more photocopies.

Using Domino to Automate Change Requests

How does Domino handle this process? The Domino application determines who the process owner and reviewers are. Domino automatically emails the process owner with a notification of the new change request. The message includes a link to the actual document, which can then be opened. The process owner can assess the change request and approve it on the spot, releasing it to the reviewers. Releasing it generates email to the reviewers, again including a link to the change request. Rather than making the administrator responsible for ensuring a timely response, a Notes agent runs nightly on the server, sending tardy reviewers email notices. After a certain number of tardy notifications go out to reviewers, the administrator receives a notification of which reviewers are tardy for each outstanding request. After all reviewers respond, an agent generates a notification to the process owner and administrator. Because all the notifications are automatic, the cycle time is reduced from weeks to a matter of days. Because the administrator no longer has to photocopy and distribute the change requests and supporting documents, and no longer has to call tardy reviewers, a significant amount of time is recovered.

This paragraph has only touched the surface of the engineering change request application. Even so, it is quite apparent that this workflow solution solves a lot of administrative headaches and significantly reduces the cycle time of a change request. If this were simply a shared database, none of the email notifications or the agents would be present. A send model would not enable the originator or the administrator to determine the status of a change request. There would be no automatic monitoring of reviewers.

The process works better, and the company now has a history of change requests and change orders that can be easily researched. Before this, the only research involved a large file cabinet where copies of the old change requests were supposed to be stored. With the full-text search capabilities of Notes, this application became a very sophisticated tool for the engineering firm. The application was completed, tested , and debugged in about 300 hours of development.

The combination of the two technologies ”shared databases and messaging ”obviously had a significant effect on this application. This is a classic example of a workflow application and shows how Notes and Domino can benefit an organization in a short period of time. User acceptance has been very positive, and a tremendous burden has been lifted from the administrator's shoulders.