Chapter 17. Workflow systems

Workflow systems are critical in a unified content strategy because they help to ensure that content flows smoothly through the content life cycle. Workflow systems make sure that everybody contributes the required content, that content is reviewed and approved at the necessary stages, and that it is delivered to its various outputs. Rather than relying on manual processes, workflow systems automate them, handling the interrelationships among processes and tracking the status of the project at any given time.

Workflow systems allow work to be assigned, routed, approved, acted upon, and managed with system-controlled rules that you set up when you design your workflow. (For more information about designing effective workflow see Chapter 11, “Designing workflow.”)

Workflow systems may be included as part of the content management system you select, or they may be stand-alone systems. If your content management system (CMS) has workflow included, it is particularly important to ensure that it meets your needs. Sometimes embedded workflow systems are specific to only one application of content, or they may be very rudimentary in their functionality.

Suggested vendor questions are included throughout the chapter. For more information on selecting an appropriate vendor see Chapter 13, “Evaluating tools.”

This chapter describes what workflow systems should be able to do to support a unified content life cycle. Workflow systems consist of three major components, as shown in Figure 17.1: creation, processing, and administration. All are critical in managing a unified content life cycle.

. Workflow components.

Figure 17.1. . Workflow components.

Creation

The creation component enables workflow authors (for example, information architects or business analysts) to create and test workflow processes. Creation typically consists of:

  • Process flow creation

    Workflow authors create graphical representations of the workflow, selecting from predefined interactions (for example, print) or creating new interactions if required.

  • Process testing

    Workflow authors can use test data to simulate a process. Testing workflow under a variety of circumstances before implementing it can be extremely beneficial.

  • Ability to learn

    Some workflow tools learn from user interactions, creating new workflows based on their analysis of user processes. Your organization can review the automatically created workflows for validity and usefulness. This capability is not the norm in most workflow systems, and it is not a “must have,” but it is “nice to have.” By identifying repetitive processes, the workflow system can help to point out areas where workflow could be automated.

Vendor questions

When you’re evaluating a workflow system, consider what you want it to do in relation to your unified content life cycle and who is going to perform these tasks. Ask vendors the following questions:

  • How easy is it to create the process flow (for example, can a business analyst easily create workflow or is a technical specialist required)?

  • Is the user interface graphical? Is drag-and-drop of workflow elements supported?

  • How easy is it to create a workflow (that is, what is the methodology)?

  • Are there any predefined workflows (templates) that can be used or modified as necessary? Is integration provided for other modeling tools or business process re-engineering tools?

  • How easy is it to simulate and test the workflow processes? Can you set up multiple test data scenarios to test exceptions and conditions?

  • Can the system learn from user interactions and create new workflow based on its analysis of user interaction?

Processing

The processing component of a workflow system activates and manages workflow, handling such things as routing work based on rules you set up when you design workflow.

Routing

Routing moves work through the workflow system. For example, after content is identified as ready for review, it is automatically routed to the reviewers, or reviewers are notified that the content is ready for review so they can link to it. Work can be routed in a number of ways:

  • Sequential

    Sequential routing moves work through the workflow in a linear fashion. As a step is completed, work is automatically routed to the next step in the process. For example, content that is identified as ready for review is automatically routed to reviewers. Sequential routing is the simplest form of workflow.

  • Rules-based

    Rules-based routing enables the system to determine how to route content based on logic. For example, if this is content for Product X it should be routed to the Product X reviewers, but if it is for Product Y, then it should be routed to Product Y reviewers. Rules-based workflow enables the system to make intelligent decisions about how to handle work based on certain conditions. Rules also assist in handling exceptions. For more information, see the “Rules” section later in this chapter.

  • Parallel

    Parallel routing routes work simultaneously, so one part of the work isn’t delayed while another part is completed. For example, content for a new brochure can be assigned at the same time as the graphics; the graphics don’t have to wait for the content to be finished. However, you may want to include a “wait” step at the end of the parallel processes before the work continues through the flow. For example, if graphics are completed before the content, you could include a wait step to hold the graphics until the content is complete so they can be integrated for review.

  • Ad hoc

    Ad hoc workflows do not follow a set of rules. Instead, they involve human decisions. Ad hoc workflow is the least used, but can be useful to assist in one-time or unplanned situations. For example, if you have to issue an addendum immediately to announce a change in staff, or to correct a problem users are having with a product, ad hoc workflow lets you route content only to where it’s needed immediately, bypassing those people or processes that don’t need to be involved. Ad hoc workflow is also useful when it is not possible or necessary to apply a rule to a decision.

Vendor questions

In assessing what kind of routing you need a workflow system to support, refer to your unified content life cycle and review your workflow design. After you decide what you need, ask vendors:

  • What types of routing are supported? Can the system provide ad hoc workflow if you need it?

  • Does the system allow steps to be completed simultaneously? Are wait steps supported?

  • How easily can a workflow of one type be changed to a workflow of another type?

  • Can you have different types of routing for different projects? How easy is it to create the different types of workflow routing?

  • Can multiple routing types be supported simultaneously? For example, can you have rules-based and ad hoc workflows working in parallel?

Rules

Rules define what happens under what circumstances. They determine how content and tasks are routed through workflow. For example, when content has been identified as “ready for review” (that is, the author has selected “ready for review” metadata), that content is either routed automatically to the reviewers, or reviewers are notified that content is ready for them to review. The rule may look something like:

if metadata = “ready for review” then step 3

Rules should also include exceptions to the normal situation. An exception to the rule tells the system how to process a task when it does not meet all the requirements to continue through the workflow. For example, what happens if three reviewers have been assigned to review some content, two reviewers have completed the review, and the third is on vacation? The exception tells the system to automatically route the content to an alternate reviewer. What happens if that reviewer is off sick and no one else is identified as a reviewer in the workflow processes? If the rule states explicitly that content must have three reviews completed before it can move to the next stage in the workflow process, the content will be delayed until a third reviewer is available. An exception could state that if a third reviewer is unavailable, to route the content as though it had three reviews, or to route the content to a manager to decide whether the two reviews suffice.

For example, the rules may look something like:

If reviewer3 = “not available” then “alternate1”

If alternate1 = “not available” then “alternate2”

And so on.

Vendor questions

Rules are critical in a workflow system; they determine what happens to content at any given stage in the workflow processes. Remember that workflow should not always be “carved in stone” and may need to accommodate exceptions. Ask vendors:

  • What types of business rules are supported?

  • How easy is it to create a business rule (for example, predefined elements from which to select, simple rules language, visual)?

Administration

The administration portion of the workflow system is where all activity is tracked. Administration matches roles to tasks, assigning who—or which system—does what, and it manages security (who can see or do what), deadlines, and reporting when tasks are done.

Players (role assignment)

In a unified content strategy, different people (players) perform various tasks at different stages in a process, and the workflow system must keep track of who is responsible for what. For example, some players create content whereas others review and approve it. In a workflow system, the system itself is also a player (for example, after the content is approved, the system may initiate an action to deliver the content to the web site automatically or to “fill in” systematic content before delivery to a reviewer).

Although players perform many of the steps in the process, it is important to be able to assign a role to an action or a step rather than a person. Many players can then be assigned to a role and a change in a player will not require a change to the workflow. For example, Fred Turnbull is responsible for the final approval for all Product X information. He has been promoted to general manager and is now responsible for final approval of the entire product suite. Rather than changing the workflow to indicate his changed title, he is just removed from the Product X approver role and assigned to the Product X Suite approver role. His replacement within the department, if any, is then assigned the Product approver role. If there is not a replacement, the workflow won’t have to be redesigned, although those already assigned to the Product X approver role will have a larger workload. The tasks stay with the role, not the person.

To move workflow along, it’s also beneficial to assign more than one player to a role. That way, if the first person is unable to perform a task, workflow moves the task to the next person whose role is assigned to that task. For example, Nancy Smith is the senior graphic artist who creates graphics for all Product X’s web-based information products. If she is on vacation or if she declares herself unavailable for a temporary period of time, such as if she’s swamped with other work when a request comes through for some new graphics, the workflow system identifies that she is unavailable and routes the request for graphics to Michael Hotley, another graphic designer associated with that role.

Vendor questions

Assigning tasks based on roles is important in keeping the work flowing through the system. When you’re assessing workflow systems, ask vendors:

  • Can roles be assigned to a task rather than to individuals? Can a group be assigned to a role? Can alternates to individuals in a role be assigned?

  • Under what circumstances can a role be bypassed (such as by management), and an alternative workflow be applied?

  • What possibilities exist for balancing workload responsibilities among redundant or co-existing reviewers in teams?

  • Are exceptions easy to create?

  • Are temporary exceptions (for example, declaring oneself absent for the next two hours or days) easy to create?

  • How easy is it to create or change a role?

Security and electronic signature

Just like content, workflow should have security assigned to it. It should be possible to apply a security level to any part of a workflow to control who can create, modify, delete, and view a workflow.

How and where does security apply?

Security can apply to:

  • Players

  • Groups

  • Roles

  • Workflow

  • Steps

  • Tasks

  • Objects

Security controls who can start a workflow process, handle an exception, view reports, or change priorities.

Electronic signatures may be a part of security. An electronic signature, like a traditional signature, indicates that work has received some level of sign-off or approval. The ability to use an electronic signature should be strictly controlled. Electronic signatures are particularly important in regulated industries.

Vendor questions

Maintaining control of processes is critical in a unified content strategy because workflow shouldn’t be altered to eliminate certain tasks. Eliminating certain tasks or reviews can compromise the consistency of the content as well as the processes intended to create and manage it. When assessing security, ask vendors the following questions:

  • What security levels are provided? How easy is it to set security levels?

  • Are electronic signatures supported? How are they supported? How are electronic signatures verified (for example, password protected)?

  • Can a manager or administrator override the security with appropriate permission?

  • How are security changes, administration, and any violations tracked and/or reported?

  • How easy is it to set up new controls or to manage new, transferred, or departing employees? How much work is the daily maintenance task to maintain security, permissions, roles, and so on?

Deadlines and escalation

Within a workflow system, each step or activity has a deadline assigned to it. If the deadline is missed, a series of actions should occur (for example, reminder messages or escalation). Escalation actions can route the issue to a supervisor or manager to ensure the action is completed and does not hold up the process. For example, imagine that content has been routed to three reviewers, and two of the reviewers have completed their reviews and returned their comments. The third has not. The system sends the reviewer reminder messages that get increasingly demanding. After the third reminder, the reviewer’s manager is notified that the review has not been completed, and is informed of the number of days the review has been delayed. The manager speaks directly to the reviewer and the reviewer completes the review that day. Alternatively, if the reviewer is actually on vacation and forgot to inform the system of that, the manager can then activate a request for the review to be routed to an alternate list.

Deadlines can be defined to occur after a certain period of time elapses (duration), or in response to external events (as with parallel workflow, managerial discretion, or administrative changes/shifts/reprogramming), or the user can be prompted to enter a deadline. A workflow system can define different deadlines at different levels, including:

  • Step

    The step is assigned a duration deadline (such as three days) or a specific date of completion.

  • Task

    The entire task can be assigned a duration or date of completion. This means that the individual steps do not have a specific duration, but the entire task must be completed after a certain period of time has elapsed or by a specific date.

Sometimes you may find that one workflow process needs to take precedence over another process. It is important to be able to change the deadlines to reprioritize the processes.

Vendor questions

Deadlines are critical in keeping content moving. When assessing a workflow system, ask vendors:

  • Is there a way to notify users of deadlines (for example, by e-mail or an electronic calendar)?

  • Can users choose to add an alarm to a deadline to assist in reminding them of due dates?

  • Do missed deadlines trigger actions such as reminders and escalation procedures? Can priorities be changed?

  • How can deadlines be affected by external events, such as internal reprogramming, managerial discretion, and so on? How can you ensure that deadlines do not get “lost in the shuffle” when reorganization of some kind takes place?

  • How can deadlines be changed mid-stream? How are people notified?

  • Can schedules of deadlines be prepared in advance of workflow tasks? Are there ways to notify people of deadlines that are coming up, even if they can’t actually start the work yet (such as a notification that their review is scheduled to start in a few days)? Can reports be written to allow for ad hoc managerial inspection?

  • When a deadline is missed, can someone insert a comment explaining why, or that it was investigated by appropriate people/managers?

Reporting

You can create reports to monitor the status of a process, as well as individual and group performance (for example, how long it takes to create a new web page). Reports can also be automatically generated at a specific point in the workflow. For example, a report detailing who worked on a document, how long it took at each stage, and any missed deadlines, could be automatically generated and routed to management as soon as a document is signed off. Reports like these can assist your organization in collecting detailed metrics to be used to better manage your processes and determine return on investment.

Workflow systems typically provide a variety of reports. Sample reports include the following:

  • Deadline reports identify upcoming deadlines and deadlines that have been missed.

  • Work-in-process reports track what steps have been completed, the location of outstanding items, and whether or not a process is on schedule. Work-in-process reports can also determine the volume of work and any backlog in processes.

  • Exception reports identify where exceptions have occurred, the frequency of their occurrence, and who made them. Repeated exceptions may indicate that the workflow needs to be revised to avoid further exceptions.

  • Workload balance reports identify how much work a player in the process has waiting to be addressed. The report can assist managers in identifying whether one player has too much work while another has insufficient work, so the workload can be rebalanced. If the workload is frequently out of balance, the reports can help you identify that new rules need to put in place to avoid these problems in the future.

Vendor questions

Having a unified content strategy means being in control of your content all the time. You can do this only if you know the status of all your work and who is doing what, when, and how much they have to do at any point in time. Make sure you can get the information you need through the reports the system generates. When assessing a workflow system, ask vendors:

  • Can comments be added to the resulting workflow to add information about various parts of the process, such as reasons for delays, postmortem notes, and so on?

  • Can report generation itself be tracked? Can permissions to create reports be limited to specific individuals or roles?

  • How can reports be characterized? By person, task, date, department, keyword, exception, and so on?

  • What standard reports are provided?

  • Can customized reports be created? How simple is it to create a report? Can customized report templates be built for reuse?

Other considerations

Traditionally, workflow has been used to manage document life cycle processes, but workflow is now being used to manage many processes within enterprises. Although there are some stand-alone workflow tools, the majority are integrated with existing systems (for example, web content management and integrated document management systems). Like many other software applications vendors, workflow software application vendors have developed their own customized products to meet market needs. This may mean that embedded workflow systems meet the needs of the specific application very well, but may not be extensible to other uses. If the embedded workflow is flexible enough for you to extend the standard workflow to accommodate your additional needs, this may not be an issue; however, if it is not, you may need to integrate with other applications and associated workflow components. If you plan to share your workflow processes with other applications, or you plan to retrieve information from other applications, it is important to be able share information. The use of standards helps to facilitate information sharing.

Standards tend to lag behind market requirements and cannot address all customer needs, so vendors often ignore them and build what they believe will meet customer needs. In the context of a specific customer requirement (for example, web content management) this may not be a problem. However, when integrating with enterprise requirements and potentially multiple workflow systems, the lack of standards can be a problem.

The non-profit Workflow Management Coalition (WfMC) was founded in 1993 by workflow vendors, users, and analysts. Its two main goals are to define standards for workflow and disseminate information about workflow and workflow systems. A standard was defined in 1995, and modified in future years to adopt XML (Wf-XML) and address a broader base of customer requirements. The Wf-XML model is focused on coordinating process data. There are concerns that this standard will not be widely adopted.

An alternate standard, RosettaNet, is gaining wider adoption. RosettaNet is an XML standard. RosettaNet was not specifically designed as a workflow standard; rather, it has been designed to facilitate B2B (business-to-business) interactions. It defines business exchanges for specific business processes and provides a framework that allows multiple application processes to exchange data. To accomplish the sharing of data, RosettaNet provides a framework and XML dictionaries of properties. This standard is getting more interest from vendors.

Vendor questions

It’s important to figure out what you need a workflow system to do, based on your new unified content life cycle. Assess workflow systems against the criteria defined in your content life cycle, asking vendors questions such as the following:

  • Does the embedded workflow meet all your organization’s requirements, or is it specific to one application of the content life cycle (such as the web)? If it was designed for one application, is it extensible to accommodate the enterprise content life cycle? How easy is it to extend the workflow functionality?

  • What standards—if any—are used to exchange data among applications? With which systems does the workflow system integrate? How is integration accomplished? Is there an API that would allow the workflow to be customized to integrate with systems not currently integrated?

Summary

Workflow systems consist of three major parts: creation (enables you to create and test a workflow), processing (activates and manages workflow), and administration (tracks workflow).

The creation component of a workflow system enables you to create graphical representations of the workflow and to use test data to test the workflow, and it may provide the ability to learn from user interaction and automatically create automated workflow.

In the processing component of a workflow system, work is routed using sequential, rules-based, parallel, and ad hoc workflow routings. Rules define what actions should be taken at each step.

The administration component of a workflow system provides the capability to define roles, assign security to different components of a workflow, and set deadlines for each action in a workflow. Reports enable you to monitor the status of a process as well as individual and group performance.

If work and information from workflows are to be shared among applications, standards can facilitate this process. However, standards have not readily been adopted by the industry.

Here are some of the things to consider when selecting a tool:

  • How easy is it to create and test workflow? Are there any pre-defined templates?

  • What types of routing are supported (sequential, rules-based, parallel, ad hoc)? How easy is it to create the different types of routing?

  • Can roles be assigned to a task rather than to individuals? How easy is it to create or change a role?

  • What security levels are provided? Are electronic signatures provided and how are signatures verified?

  • What types of deadlines and escalation procedures can be created?

  • What standard reports are provided? How easy is it to create a custom report?

  • What standards are used for the exchange of data among applications?

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset