ing your system, you should pay particular attention to how you incorporate your company's business rules into the process design.
Finally, you must plan for success in the long run: How you maintain your
work-flow system
will determine whether the fast performance it shows in the beginning degrades over time.
Here are six fundamental reasons why work-flow systems fail. Steer clear of these pitfalls, and you'll increase your chances of making work flow work for you.
REASON #1: Not All Processes Can Be Automated
Scenario:
You need to automate your company's production line. However, because your product catalog is so varied, one process input (e.g., order entry) might have thousands of possible outcomes determined by the combination of dozens of variables, depending on your customers' needs.
Analysis:
Processes like this aren't good candidates for work-flow automation. Work-flow engines require well-defined rules and conditions, and this means you must program all possible roles, actions, and exceptions that could occur within a work-flow process. This extremely complex task requires you to work through all t
he possible outcomes in advance and program each permutation into the engine. Even if you could program and debug a work-flow system for all of a company's actions, maintaining the program would be difficult and costly.
Solution:
The quick answer is to avoid automating processes that rely on randomness and variability. But this advice is analogous to saying you should buy a car that can only make left turns. It works, but it's worthless.
A more practical solution is to keep humans responsible for the major decision points in the process--where highly variable and complex issues are most likely to occur--and use the work-flow system to move data from one decision point to the next. This approach capitalizes on two of the primary strengths of work-flow technology: communications speed and automated record keeping.
An automated work-flow system can offer a variety of communications options, including E-mail, fax, pagers, and Electronic Data Interchange (EDI). Most e
ngines support such industry standards as MAPI, SMTP/MIME, and OLE. These tools enable you to increase the speed and number of participants in the work-flow process.
In an automated work-flow system, you can compress the cycle time tremendously when you use electronic communications to move data among work-flow elements. By contrast, moving data from person to person and from task to task takes up the majority of the cycle time in a manual system.
REASON #2: Subjective Events Define Your Work Flow
Scenario:
A project manager at your company needs regular status reports from task leaders to make sure they're meeting internal schedules and to provide updates to a customer. In the current manual system, the project manager checks each report for clarity, consistency with the other reports, and proper formatting. If the project manager likes a report, it goes to the client. If not, the report travels back to the author for revision.
Analysis:
Programming this process is a challenge, because the report review relies on a subjective evaluation and human intervention (e.g., what the project manager likes or doesn't like). The simple rule is, if you can't quantify it, you probably can't program it. Today's work-flow engines cannot handle ad hoc decisions or those that require the use of fuzzy logic.
The best that a work-flow system can do in this example is to receive the draft status reports in an inbound work queue, organize them for processing by their due date, run the document through a grammar/spelling checker, and pass the results to another process, where someone could quantify and score the results. Based on the scores, the system would either forward the documents to the client or send them back to the author with comments.
Here the work-flow engine adds little value to the process, because the system can evaluate only quantitative--not qualitative--characteristics of the reports. No magic APIs or AI age
nts exist to help the work-flow engine subjectively evaluate work-flow events.
Solution:
Quantify and convert the business rules into the format your work-flow engine expects. You should document business rules using the syntax and format that the engine requires as part of your design effort. Then evaluate the process elements from the perspective of what your engine can do.
Reduce the process map or flowchart to quantifiable business rules during the design or prototyping activities. Otherwise, you'll spend a lot of time programming functions and features outside of the engine--or, worse, you'll find out late in the development or pilot stage that the work flow just can't be automated.
REASON #3: System Performance Degrades over Time
Scenario:
Your claims-processing department uses document imaging to receive claim forms in the mail and scan the data into a work-flow system for routing and processing. But someone
must manually index the documents with codes for document types, dates received, and claim numbers. The system can generate some of these indexes for date received (system date) or document ID. But for the other indexes, an operator must review each document to determine what type of document it is and how it should be processed.
Analysis:
Even if the system processes the same type of document 20,000 times in a row, it cannot learn how to automatically index these documents. Indeed, instead of getting smarter about a process, work-flow systems often get dumber.
What generally happens is that a work-flow system works fine for the first few weeks. But then, as the process ages and matures over time, slight variations creep in, so there are more and more process exceptions and a greater need for exception-handling procedures (most often outside the system). Exception handling can typically require two to three times the normal cycle time, so as more exceptions creep in, sy
stem performance degrades and overall cycle times increase.
Solution:
The best way to control a downward spiral in performance is to continuously monitor the work-flow process and change the program as the process changes. System performance and effectiveness correlate directly with the frequency and quality of the program maintenance you do. Look for engines that provide detailed audit trails, event logs, transaction monitors, and capacity alerts. These results can ease your maintenance burden and alert administrators in advance to processes that are going out of control.
REASON #4: New Tasks Corrupt Existing Designs
Scenario:
You want the claims-processing system that you designed in the previous example to implement a temporary claims-handling process for a particular client that will be in effect for the next 10,000 documents.
Analysis:
The engine cannot respond to this situation unless
you program it, and before that happens you must complete all work in progress and clear all work queues before the changes can take effect.
Solution:
Select one of the new object-oriented work-flow tools on the market, such as FileNet's
Visual Workflo
or IBM's FlowMark. Like object-oriented programming (OOP) development tools, object-oriented work flow (OOW) makes it easier for you to build complex work flows and maintain work-flow object libraries that can streamline development. It lets you develop object libraries around common work-flow-process elements, such as approvals, routings, data validation, and security. With work-flow objects, you embed the task or work-flow data within the process rules.
OOW offers several distinct advantages over the more traditional work-flow tools. OOW tools give you fundamental OOP features, such as inheritance, encapsulation, and reusability, which help you create objects that are flexible and easy to maintain.
Any changes you make to your business rules are immediately reflected in the work-flow process.
Since the data travels with the code, each work-flow instantiation is independent of the others. You can make changes to the work-flow objects without affecting work in progress. The work-flow engine can immediately recognize changes in the process when you change the object attributes. The ability to maintain class libraries reduces the work-flow development and maintenance burden.
What's the downside of OOW? The development environments are complex, and there are few OOW standards. Each vendor takes a different approach to adding OOP functionality to its tool set, which lengthens the learning curve for developers and limits any interoperability among tool sets.
REASON #5: Work-Flow Systems Aren't Heterogeneous
Scenario:
You need to design a work-flow process that spans three departments, in different cities, with users running a mixture of DOS,
Windows, and Mac systems over an IPX/SPX network. The clients connect to a combination of servers running Windows NT for applications and NetWare for file and print services.
Analysis:
You have a fundamental problem: Work-flow systems falter when running in heterogeneous environments. Few work-flow engines can operate on multiple-server platforms or support multiple-client OSes. The majority of work-flow vendors support Windows-based clients; however, multiple-platform and OS support might be way down on the list of priorities as vendors struggle to establish their core feature sets.
Solution:
Select a work-flow tool that can operate within a variable environment. Some products, such as Computron's Work Flow and Odesta's LiveLink, support almost every client environment, including Windows, NT, OS/2, the Mac, and Unix. But make sure you understand any limitations that might come up. If you're relying on a particular work-flow feature, such as c
c:Mail integration, make sure that feature is available on every client you might use. For example, some features that work on a Windows client cannot work on a Mac client (e.g., OLE 2.0 Controls) and vice versa.
REASON #6: Work-Flow Systems Aren't Scalable
Scenario:
You need a work-flow process that supports 1000 concurrent users for an accounts-payable system. You have a work-flow engine residing on a server in Chicago. Users in Dallas, San Francisco, and New York cannot participate in the work flow unless they are connected to the Chicago work-flow server. However, unlike E-mail or groupware products that employ server-to-server communication, work flow requires centralized processing.
Analysis:
Most work-flow product vendors design engines to maintain constant control over each work-flow instantiation in progress. These engines do not share work flows or exchange business rules with other engines.
In most cases,
you must store work-flow business rules on one server so that the engine can track and monitor all events and conditions centrally. This kind of architecture limits the ability of a work-flow system to support enterprise-wide and inter-enterprise processes, and it also restricts work flow to workgroup or departmental processes.
Solution:
Scalability and enterprise applicability are the next logical steps for work flow. If you need this capability now or want to position your work-flow applications for the future, choose a work-flow system that's moving toward distributed work-flow engines and work-flow engines that can link to internal and external networks, such as the Internet.
Action Technologies'
Action Workflow Metro
connects work-flow clients to work-flow engines sitting on top of World Wide Web servers. Other vendors, such as Netscape and Microsoft, are currently build-ing work-flow capabilities into their Internet browsers.
In addit
ion, it's possible that in the future you might be able to use Sun's Java and IBM's VisualAge to transform browsers into full-featured work-flow and transaction-processing clients that support connections to multiple work-flow servers. Users would download applications from a Web server into a Java interpreter residing on the client. One of Java's promised benefits is that work-flow applications can be platform-independent, because the Java client interpreter has the ability to translate the application into code that the client OS and GUI can understand.
Web work-flow engines might also be able to interact with each other to exchange business rules, works in progress, and information about work-flow resources. Functions such as transaction security, data validation, and event logging will also become part of the engine's responsibility. Order-processing, customer-service, and technical-support work-flow systems might one day all become commonplace over the Internet.
Growth Experience
Work-flow products are currently still immature, but they are not alone in failing to solve some of computing's grand challenges. After all, few technologies support multiple platforms, locations, and applications while also eliminating human interaction.
The effectiveness of work-flow systems should improve when subsequent generations of products appear. In the meantime, there's simply no substitute for good programming fundamentals and a deep knowledge of your company's business processes.
WHERE TO FIND
Action Technologies
Alameda, CA
Phone: (800) 967-5356 or (510) 521-6190
Fax: (510) 769-0596
Internet:
http://www.actiontech.com/metrotour/
Work Flow Without Fear
