An earlier draft of this page was discussed by the ITANA group on Aug 20. Some content has moved. Please see the enterprise workflow home page.

Scenarios

The typical components of a workflow solution can be implemented in many different ways, resulting in substantially different solutions or scenarios. The following scenarios illustrate three kinds of workflow solution. These scenarios suggest "levels" in a "progression", but in practice institutions are likely to have several approaches to workflow at once, with "enterprise workflow" as their long-term goal.

Workflow within a business system

For example, a web content management system may route content revisions to multiple approvers before publishing. Workflows are probably developed within the system in a system-specific process. They are stored and executed within the system; they may even be "built in", i.e., configurable but not re-programmable. Users are authorized according to permissions and roles defined within the system; perhaps the system refers to an external directory for groups and identities. The system provides all the necessary user interfaces; users may also receive email notifications. There is no need for the system to interact with other systems to complete a workflow. The system is managed by a team that supports workflows as just another feature of a larger solution.

  • Pro: Many business systems provide some simple form of workflow "for free".
  • Pro: May be most appropriate for truly small scale workflows.
  • Con: Often these workflows capture only part of a larger business process, where it intersects with the particular business system. Users may even be required to participate in more than one workflow in different systems to complete a process, and it may be necessary to manually keep data in sync across these systems.
  • Con: Workflows defined within a business system typically are not portable. For example, it's common for the workflow definition language (if any) to be specific to one system.
  • Con: Workflows are usually developed in proprietary language within the application.

General purpose standalone workflow

For example, a document management system with significant workflow capabilities may be used to provide automation for multiple business processes and across business domains. Workflows in this scenario typically involve routing a form from user to user to complete a process. Workflow definitions may or may not be standards based and portable. They are stored and executed within the system. Users are authorized according to permissions and roles defined within the system; perhaps the system refers to an external directory for groups and identities. The system provides all the necessary user interfaces; users may also receive email notifications. The system does not interact with other systems to complete a workflow. The system is managed by a team that focuses on workflow and works with business units to automate business processes.

  • Pro: It may be relatively easy to improve some business processes, formalize some business knowledge, and demonstrate the value of workflow with a standalone solution.
  • Pro: May be most feasible for institutions with scarce resources for infrastructure and integration.
  • Con: Many common business processes result in transactions in core business systems. In a standalone workflow solution, such workflows can't reduce repeat data entry; can't be fully monitored or audited (because the transactions generated in the core business systems are not visible to the workflow solution); and require participants to be trained in multiple systems.
  • Con: In the absence of enterprise authorization, the standalone workflow solution has to maintain its own user permissions and these must be stringently coordinated with permissions in any other business systems that users need to interact with to complete a workflow.
  • Con: Still have white space problems where a transaction gets stuck on someone's desk.
  • Con: Harder to diagnose problems with the whole business process.
  • Con: Requires duplicate entry and synchronization of changes

Enterprise workflow

In this scenario the goal is to integrate workflow across systems, making workflow an enterprise infrastructure resource that provides capabilities on top of other systems. Workflows are developed according to a standard and may be built from re-usable sequences designed for the enterprise's various core business systems. Workflows are stored and executed within a central workflow infrastructure, but this interfaces with other systems to carry out workflow steps, such as creating a transaction in a core business system. (Some of these systems may also manage their own workflows internally.) Users are authorized according to centrally managed permissions, roles, groups, and identities. Different users may see a variety of user interfaces (email, web dashboard, portal, development tools, data warehouse reports). The system is managed by a team that works with business units as well as the IT teams that manage the systems to be integrated.

  • Pro: Offers the most comprehensive centralized management and monitoring of workflows.
  • Pro: Offers the greatest scope for business process re-engineering, because workflows can eliminate more human data entry steps and access more information for automated decision making.
  • Con: Places the most demands on business (for process design and management) and IT (for infrastructure and integration). Of course, you may consider that both are essential to the development of your institution, so it's a "Pro" rather than a "Con".
  • Con: requires the most integration work
  • No labels