The intervention will usually consist in manage rules based on
The Workflow Engine is a cross - enterprise-wide, routing and approval enabling application which is built on open standards, n - tier and vendor neutral architecture.
A software service or "engine" that provides the run time execution environment for a workflow instance.
A workflow engine can control the execution of a set of process, or sub-process, instances with a defined scope determined by the range of object types, and their attributes, which it can interpret within the process definition(s).
The Workflow engine is totally web based and configurable that can control and execute the set of processes it is implemented for within an application or across the applications on integrated IT environment. The rule driven workflow engine provides for a framework to configure rules that are applicable for specific business processes within an enterprise/business unit.
The strength of the Workflow engine lies in its ability to seamlessly integrate with any existing system and enhance and extend them into workflow domain.
The proposed solution is intended to handle
Types of Workflow Systems
Workflow Management Systems have evolved into a number of recognizable forms. Each has its own merits and quirks, and each deserves review. Additionally, none of these distinctions are cut-and-dried; overlap exists.
Production Workflow Systems are geared towards efficiency, throughput, and process improvement. They allow the company or department to define how they perform a business process, and then they execute that process. These products have tools for process definition (usually graphically representing the process in a flowchart-type view), user (and resource) management, auditing and integration. In Production Systems, the process belongs to the company or department management. Often, processes are designed, reviewed, and redesigned repeatedly, usually with the input of the participants. However, management owns the process, and modifications must go through it. The exception to this is the case where a process breaks down. Most good Production Systems recognize the old saying about the best laid plans and allow individual jobs to be modified to solve a particular problem.
Ad Hoc Systems
On the other hand, in Ad Hoc Systems, the participants own the processes. At every step in the process, the participants have the ability to completely change the process. In fact, in many Ad Hoc Systems, there is no formal process at all. Ad Hoc Systems still provide the basics of Workflow Systems; they route work, provide visibility (at any time, the history of the item can be viewed), and aging (they can all specify timeouts).
Additionally, most ad hoc systems have an administrative tool that allows management to view any of these processes, including their histories. Ad Hoc Systems focus on two things: Defining destinations (often called queues) for users to direct the process to; and passing information (in the form of attachments) between participants. Process definition and execution are no longer the focus.
Message-based (Administrative) Systems
Given that both of the primary goals of Ad Hoc Systems (defining destinations and providing attachments) are available in modern email systems. In fact, both Microsoft and IBM have included basic ad hoc workflow functionality into their groupware products, Outlook and Lotus Notes. These systems (and others like them) are often called Message-based or Administrative Workflow Systems. In these systems, users create Routing Slips for messages and fire off requests to the people in the list. The slips can be modified at any time, and a history is kept on each message. By including a public folder in the slip, groups can be included, and processes can be archived. These systems are great for simple ad hoc tasks because they require little if any training to use them properly. However, they do not help management get information about the efficiency or effectiveness of processes, nor do they help automate tasks.