Offer

Offer is a state in which an executor of some work item is being wanted or a state in which some participant is being asked to execute the work item.

Overview of Offer
In workflow research, Offer is one of the states of work items and means a state in which someone is being requested to execute some work item. Although a participant offered is a candidate of a executor of the work item, he/she is not yet in charge of the work item. So, the participant offered does not necessarily execute it. Therefore, offers for some work item could be made to multiple participants. When an executor of the corresponding work item is assigned from participants offered, the state of the work item is changed to "Allocation state." Once the state of the work item is changed to "Allocation state," the assigned executor has to execute the task. Sometimes the state can be changed to "Allocation state" without going through "Offer state."

Some examples of "Offer state" are: a state in which some petition is submitted to a window, a state in which someone is being asked whether he undertakes some task or not, a state in which executors of some task are being wanted, and so on.

Besides "Offer state," processing states include "Create state," "Allocation state," "Start state," and "Complete state." In addition, manpower and physical resources required to execute a work item are called resources even though we called them "candidates for a work item" above.

Resource Model
Resources mean manpower and physical resources that are necessary to execute work items and are classified as either human resources or non-human resources, such as factories and equipments. Resources are basically members of an organization and belong to one or more departments in the organization. In addition, each resource is assigned a rank in the organization and has a capability to allocate other resources before starting its own task. Non-human resources are categorized as either durable resources or consumable resources. Durable resources can undertake work items without being affected by the number of work items that they are in charge of. On the other hand, consumable resources are consumed, either partly or entirely, to complete work items.

Each resource has a schedule and history. A schedule is a list of work items that the resource is going to undertake in the future while a history is a list of work items that the resource has completed.

Patterns of Offer
There are two patterns of offers. One is asking each resource to execute some work item, and the other is letting multiple resources know existence of some work item.

The former is done by requesting a resource capable of the work item to execute it or by adding the work item to a list of executable work items that can be browsed by the resource. Under this pattern, we need to determine which resource is the most appropriate among resources that can execute the work item, and we must choose the most suitable resource by ranking resources.

The latter is a pattern in which the most suitable resource is chosen after the existence of a work item is announced to multiple resources. This is analogous to recruitment of part-time workers.

State Transition of Work Items
It is also called a life cycle of work items. Basically, a state of a work item changes as follows. Sometimes the state changes directly from Create to Allocation, skipping Offer. In addition, there is "Fail" state in case a resource can not complete the work item and does not work on it again. Note that only one resource actually undertakes a work item while multiple resources can be offered. Thus, allocation is done only to one resource.
 * 1) A work item is ready for execution. (Create)
 * 2) Candidates for the work item are chosen. (Offer)
 * 3) A participant to execute the work item is chosen. (Allocation)
 * 4) A work item is started or in progress (Start)
 * 5) A work item is completed (Complete)

By way of exception to this state transition process, there are Detour Patterns, which categorize special processes that skip a work item, leave a work item to another resource, or suspend and resume a work item.

State Transition without "Offer State"
In some cases, a work item becomes "Allocation state" without going through "Offer state." Such cases happen when a certain resource is allocated without being asked whether it intends to undertake the work item or not or without making offers to other resources.

In these cases, the resource often does not know at all or almost nothing about what the work item that it undertook is like. As soon as the resource completes one work item, a new work item is allocated. And then the resource is required to start working on the new work item without knowing what it is required to do next.

The purpose of such transition is to maximize the processing capability by making resources always busy.

Creation Patterns
Creation Patterns are the pattern categorizations of the ways in which states of created work items are changed to Offer and Allocation. There are capability-based approach, achievement-based approach, and so forth. There are 11 patterns shown below.
 * DA (Direct Allocation)
 * RBA (Role-Based Allocation)
 * Deferred Allocation
 * Authorisation
 * Separation of Duties
 * Case Handling
 * Retain Familiar
 * CBA (Capability-based Allocation)
 * HBA (History-based Allocation)
 * Organisational Allocation
 * Automatic Execution

Related Articles

 * Allocation
 * Workflow Engine
 * Workflow Pattern
 * Participant
 * Swimlane