Lotus Domino/Notes and Microsoft Exchange Server have brought the productivity of groupware and work flow to our desktops. True automation of the way organizations work is becoming simpler to mimic with new applications and software that employ environments such as Domino/Notes and Exchange Server. These applications exploit the workstation desktop, the standard for business computing. Where does that leave traditional 5250 applications? Well, tools do exist that bring much of the work flow and process management power of groupware to the traditional environment.

Virtually everything done in business consists of some sort of process. Place tab A into slot B, fold at line C, and place completed assembly into box D. Or submit purchase order A to manager B, but only if amount exceeds value C; otherwise, place into basket to await arrival of invoice. And so on. Any organization with a certification like the ISO 9000 (a family of quality assurance program standards approved by the International Standards Organization) knows the drill, since certification requires that processes be documented in detail. The incredibly imaginative name given to this aspect of business is work flow.

Manually executed processes have existed since the dawn of commerce and will continue to exist, but some processes are better served by applying automation techniques—techniques that may be a bit unfamiliar to those comfortable with transaction- based procedural programming. Suppose the question is asked, “How many widgets have completed the slot B step and are awaiting the folding step?” Some software systems, especially in the manufacturing field, can answer this question at least partially, but other systems may not even be aware of the existence of the widgets until the entire process is complete.

How Deep Is the Problem?

A similar question posed to the accounts payable department in this example is likely more difficult to answer, regardless of the managing software. A railroad based in the western states was, at one time, rumored to have measured its accounts payable backlog—literally the heights of the piles of unprocessed and in-process vendor invoices—in feet. Any reasonable, much less exact, measurement of the state of that piece of that business was nearly impossible to obtain. For many businesses and units within those businesses, there

is a distinct need to control the process. Without control, measurement is difficult, if not impossible; productivity, customer service, and quality all suffer.

How can an organization better manage or regain control of its processes? This article explores the basic concepts of automated work flow and examines an option available for software applications not typically considered a candidate for this sort of capability.

The Pieces of Work Flow

At its core, every process has a single unit of work. In manufacturing, the unit of work may be a finished product or subassembly. In an order entry application, the unit of work may be a customer order. In accounts payable, it may be an internally generated purchase order. Each unit of work proceeds through one or more process steps from inception to completion, but the actual processes affecting the unit of work at a particular step are not addressed in work flow. Assemblers assemble, clerks enter data, pricers price orders, and so on. The work flow aspect addresses movement of the unit of work only between steps. As a unit of work moves through a process, only three work flow concepts typically apply: queuing, pending, and routing. It is the intelligent splicing of these concepts that brings true power to work flow automation of the process.

Queuing is simply the mechanism that stages work for a particular process step. Email inboxes are work queues; letter trays are work queues. Over time, organizations have developed a huge variety of these mechanisms, but most are based on the simple concept of a pile: An item is removed from the bottom of the pile to be worked on, and new items are added to the top. It is when the order of items to be worked on needs to be adjusted that a manual system begins to break down. Management is also an issue; how deep is the pile?

In work flow systems, queuing generally takes a form similar to the typical email inbox. Individuals or groups of users receive a list of things to do and are expected to work on the top item first. However, through the magic of software, rules can be applied to an item’s position on the list. Items with higher priority bubble up to the top of the list, and appropriate application of aging algorithms ensures that all work is addressed in the correct order of priority and in a timely fashion. In addition, measurement is simply an exercise in querying the number of items on the list.

Often, a unit of work must stop and wait. Maybe the unit is waiting for a response from a customer or waiting for some part to arrive. Sometimes, the unit is even waiting for the lack of a response, such as in a customer care application where, if the customer does not respond within a given period of time, the issue is considered resolved. This act of stopping work is known as pending.

Moving work between process steps requires routing. If email is received and forwarded on to another individual for further processing, that is routing, specifically manual routing. Paper and folders have been routed through organizations for decades, but an automated work flow system has the ability to affect work routing with things the system knows about individual units of work. In today’s world of automated systems, a unit of work doesn’t necessarily have to involve paper.

One interesting aspect of many work flow systems is the ability to move work along in a process in parallel fashion. If the process does not require steps to occur serially, two or more users can act on the same unit of work at the same time. The system ensures that all users complete their pieces of the puzzle before moving the unit of work along in the

Queuing

Pending

Routing

process. While parallel processing is very difficult to implement in manual systems, computer automation has made concurrent processing fairly easy to achieve.

Most work flow systems also implement the concept of process variables. A process variable is simply some piece of information that travels with a unit of work. Uses for process variables include conditional routing of the unit of work and storing bits of information such as performance data or unique attributes that may not reside in any database.

When an individual completes labor on a unit of work, the unit is returned to the work flow and routed to the next step based on its process variables or on some indication the last user made. A unit of work may need special attention from a supervisor or other specialist; most work flow software provides options for users to affect routing accordingly.

Applying the Concepts

Work flow software tends to implement these basic concepts in different fashions. For example, Lotus Domino/Notes uses the basic concept of a form to implement its work flow features. A form is created, and macros are attached to fields in the form to route the form or otherwise act on it. Values in the form fields may constitute process variables. More recently, the LotusScript development facility has supplied a scripting (procedural programming) option to the basic form concept.

Microsoft Exchange Server also touts itself as a groupware offering. Developing an Exchange Server work flow application requires development of one or more Visual Basic for Applications (VBA) programs, which are essentially similar to the Domino LotusScript capability. A form facility is also available with Exchange Server and is often an integral part of an Exchange Server work flow application.

Other work flow systems use a table-driven concept: Entries in tables or process charts control the flow of the unit of work. The advantage to table-driven systems is typically the reduction in need for programming skills often necessary for development of scripts and macros.

Building Flow

Methods for defining a process vary. With script- or form-driven systems, programming defines work flow. Some work flow systems try to simplify programming tasks through implementation of a work flow language, a special dialect with language operators specific to work flow tasks. Other scripting environments simply provide a set of work-flow- specific functions. In any case, some knowledge of procedural programming and some development experience are usually required to devise a work flow application.

Some sort of graphical capability to define a process is generally the simplest way to develop a work flow scenario. A pictorial representation of the process can be drawn on the screen, and necessary back-end components are then generated from the picture. Several vendors offer graphical definition products that generate scripts, programs, and macros for many of the popular groupware offerings. Other work flow products deliver graphical definition tools with the software.

What About 5250 Applications?

Domino, Exchange Server, and virtually every other work flow software package are all well and good for applying process automation to workstation-based applications and client/server applications that offer appropriate interface points. However, there exists a huge base of traditional 5250 character-based applications. Many of these solutions will be in use for another 10 years or more and could benefit from the addition of work flow features.

Although it is true that many workstation-based work flow products can interact with 5250 applications through an emulator screen (screen scraping, as it is often referred

to), IBM’s Content Manager for AS/400, with its Advanced Workflow option, offers a truly native means of applying work flow to any application, whether traditional 5250 or workstation-based. (Editor’s note: On March 14, 2000, IBM announced [announcement letter 200-044] that the name of ImagePlus VisualInfo for AS/400 was changed to Content Manager for AS/400.) You may know Content Manager as the IBM product often applied to electronic document management (scanned image) applications on the AS/400, but, beginning with V4R3, Content Manager was equipped with a powerful table-driven work flow facility. This facility includes a rich set of workstation and host-based programming interfaces, both exit points, where application components can be inserted into the work flow process, and APIs, where an application can make calls to the work flow facility. Process definition is accomplished with a Windows-based graphical setup tool.

Content Manager implements all the work flow concepts defined above. A unit of work is referred to as a “work package” and doesn’t require document images to operate. Queues are implemented as workbaskets, and pending is accomplished through a mechanism called a collection point. Conditional routing is supported through use of process variables and a set of user control functions known as the action list. Finally, conditional routes are controlled through an element known as a decision point. Figure 1 shows the icons that represent these concepts in Content Manager’s graphical setup tool.

Building the Process

So how is work flow typically inserted into an application? A detailed study of the process is required, with particular attention paid to exceptions that occur along the way. Just like in traditional programs, about 20 percent of the process definition is associated with the normal flow of work and supports about 80 percent of the workload. That leaves 80 percent of the process definition to address exceptions related to the remaining 20 percent of the work. A variety of complex methods exists for documenting work flow, but a traditional flow chart is often more than adequate. (A full explanation of how to go about documenting a process is well beyond the scope of this article, but a variety of good texts on the subject exists.)

Once documentation is complete, development of the automated process can begin. Start by defining workbaskets, the places where work stops and waits for a user to act on it. (In Content Manager, this step must currently be done using the 5250 interface.) Once a workbasket definition is complete, activities can commence in the graphical tool. The predefined workbaskets are placed in the workspace, and collection points and decision points are added for conditional routes.

Collection points, Content Manager’s pending mechanism, hold a work package either for a specified number of days or until some set of external events occurs. In a document-oriented application, an external event may be the arrival of a document. Events may also be programmatic or may simply be the completion of another part of the process. Content Manager provides an API that allows an application process to satisfy collection points programmatically. All collection points must have an event that expires in a specific number of days associated with them to ensure that work packages aren’t lost in the ether forever.

Process variables can be set to specific values in the design process or through an API call in a program as a work package moves through a process.

The final definition step is to connect all the process elements, workbaskets, decision points, and collection points with lines in the graphical tool. The lines represent work routes and are checked for basic validity as they are created. The graphical design tool identifies routes that can result in infinite process loops and enforces a default path for all work, regardless of what conditions are set. The default route again ensures that work is not hopelessly lost in the process.

Figure 2 shows an example of what a simple accounts payable process might look like when drawn in the Content Manager definition tool. The top half of the window

contains the graphic design workspace, and the bottom portion is a tabular representation of the process. Either section can be used to develop the process.

Once the process definition is complete, all that remains is to connect the process to the application. Unfortunately, Content Manager is primarily a client/server product and, as such, doesn’t provide a 5250 screen interface, except for some administrative functions. This means that some development of programs and screens used to support lists of work in workbaskets may be required. A basic example of how to call APIs from RPG IV is included with the product, along with a reasonably complete RPG header file.

The Benefits

Once an application is enabled with work flow technology, a virtual plethora of information is available. Since Content Manager is a table-driven product, all information regarding the process and the status of work packages in the process is stored in the same DB2 UDB database as data from the application. Query tools, familiar to users and developers alike, are used to report on the status of work. Exact backlogs can be measured, and new information can be added to resource planning. Measurement of the process is no longer a guess; the effect of even a small procedural change to the performance of the process is known almost immediately. As with any technology, however, improper application of work flow can just as easily cause as many problems as it solves. A little study on the front-end of a project can go a long way toward avoiding problems on the back-end.

Good work flow technology is available for traditional 5250 applications, and implementing it is a reasonable task for any development organization. Even the railroad with the big problem mentioned earlier was rumored to have completely eliminated its accounts payable backlog within just a few months after implementing AS/400-based work flow.

References and Related Materials

• Fundamentals of Workflow Automation and Process Redesign. Herman Silbiger. Silver Spring, Maryland: AIIM International, 1999
• VisualInfo for AS/400 4.3: Planning and Installation Guide (GC34-4585-01, CD-ROM EKD10K01)

Home plate: the start of the process Workbasket node: Content Manager’s queuing mechanism Decision point node: Content Manager’s conditional touting mechanism Collection point node: Content Manager’s pending mechanism Stop node: the end of the route or process

Figure 1: IBM’s Content Manager (formerly VisualInfo) graphically represents the basic work flow elements.

Figure 2: Defining the work flow process is simply a matter of drawing a diagram.