NETTING IT OUT

Workflow has changed since its most visible days of the mid 1990s. What started as a market for workflow toolkits with which to build business processes from scratch has changed into an embedded enabling technology found in almost every enterprise application.

But embedded workflow is too limited; only work done within the application can be effectively monitored and managed. Today, as business processes span departments, functions, applications, and even organizations, we need visibility into all activities that make up the business process, no matter who does them or what application is being used.

And, in this new world of complex and inter-enterprise business processes, the need emerges for Adaptive Business Process Management. We can no longer anticipate exactly how processes will run; what used to be the occasional exception has now become the rule. Workflow, in the new century, will have to be flexible enough to build processes that can dynamically respond to the ever-changing way we do business.

WORKFLOW IN THE 1990s

A Thriving Market that Never Was

About the middle of the last decade of the twentieth century, the hottest technology around was workflow automation. Workflow tools were designed to let you capture and automate those routine clerical business processes that involved a lot of paper pushing (insurance claims adjustment was the prototypical workflow process). By automating the different steps of a standard process, you could realize significant cost savings by reducing personnel, eliminating errors, and ensuring that nothing fell through a "black hole" between someone's outbox and the next person's inbox. Add to this the improvement in customer satisfaction that resulted from faster completion and the ability to find out exactly where in the process "my claim is," and workflow obviously was a technology that couldn't miss.

But it did. The concepts were appealing, but the packaging of the functionality was not. You see, you basically bought a toolkit with which you could build, well, anything--any business process that required the three "Rs" of workflow: Routes, Roles, and Rules--the order in which tasks are to be done, by whom, as determined by business conditions.

But, basically, you were expected to "roll your own" (create your own processes from scratch) or work with an integrator to build the process for you. The value proposition was that, once you bought the workflow engine and trained your IT people on using it to develop a process, you could leverage the investment to automate more and more processes throughout the enterprise.

But even in the flush economy of the '90s, companies would only spend money on solutions to a specific problem, not a toolkit of capabilities with which they could build solutions. Soon, the term "workflow" became almost as unwelcome as "AI." As a result, many workflow vendors disappeared (or became basically invisible even if the company continued to exist). Leaders in the market took differing strategies to continue providing workflow:

* FileNet, the leader in imaging-based workflow, changed its product category to "business process automation."

* Staffware, the international leader of electronic workflow, focused on its VAR channel who sold, basically, turnkey solutions to their customers, minimizing the toolkit aspect of the product.

* IBM, a strong contender with its FlowMark product, repositioned the workflow capabilities as part of the MQ Series of tools (now WebSphere) used by IBM Global Services and other integrators as they build solutions.

WORKFLOW AT THE TURN OF THE CENTURY (1999 TO 2001)

The Return of "Workflow"

Over the last year, the word, "workflow," began creeping back into our lexicons, but this doesn't mean that the toolkit model is returning. Rather, companies are recognizing that they need to create effective business processes to respond to customer requirements. The three "Rs" are as valid in today's process design as they always were, and we need all applications to have those capabilities.

Embedded in Enterprise Applications

Workflow capabilities were too valuable to disappear. So the vendors of enterprise applications started including workflow capabilities within their solutions. Starting with SAP, all the major ERP vendors provided workflow engines to automate those mission-critical operations within an organization. And practically all the CRM vendors, whether they sell suites or single products, such as campaign management tools or sales force automation products, have an embedded workflow environment, including a graphical process designer, execution engine, and status monitoring.

Thus, workflow moved from a discrete product category to become embedded technology--part of the solution environment, not the solution itself. Today, you'd be hard-pressed to find an enterprise application that didn't include some form of workflow.

And this makes a lot of sense; after all, people live in their applications, not in the workflow environment. However, the promise of workflow is that, in addition to living in your familiar application context, you can also see your part in the overall process. You know what work is coming to you and where it has to go. You understand the interdependencies among all participants in a process--if you don't get something done, you can see, very clearly, how the process is impacted.

Limited to Those Applications

However, there is a limitation to application-embedded workflow; the processes are limited to the scope of the enterprise application. For example, very effective business processes can be built that even span a variety of the SAP ERP applications. But, when the business process has to leave the SAP environment, the workflow tool basically just has to wait until work is returned to SAP. Any other applications that are launched as part of the process, such as a CRM application or collaboration workplace, are "black boxes" where work is being done, but the workflow can't keep tabs on what is happening.

And these virtual blinders are not just within the application, but are also on the participants. You don't know when work is coming to you; you don't see the interdependencies; you can't adjust your work within the application to the needs of the process as a whole.

WORKFLOW TODAY

Support for Meta-Process Management

Today, we need a new approach to combine embedded workflow with an overall view of the complex business processes that we need to implement to conduct effective global business. We recognize that business processes span departments, functions, applications, and even organizations. Customers must be part of the process and must have access to the information. Partners and suppliers are key participants in fulfilling the goals of these inter-enterprise processes. And, often, a large number of applications must be used to complete the process--applications such as CRM systems, inventory systems, and collaboration tools.

With business processes spanning departments, applications, functions, and organizations, a new requirement arises...