| Table of contents [hide] |
Semi-formal summary of introductions to Workflow Management
The goal of this page is to collect and represent important semantic relations between important concepts of Workflow Management. The representation is semi-formal: the adopted notation and conventions permit to represent a semantic-network that has a logic-based interpretation but some parts (typically the sentences within quotes) are just strings (their content is in English, not in a notation that machines can understand and exploit).
One of the rationales for this page is to permit the quick retrieval of important concepts of Workflow Management and their relationships, and hence help their discovery, comparison, understanding and memorizing. Indeed, in books or articles, these concepts and their relationships are scattered and hidden within hundreds or thousands of sentences, and sometimes presented in very general and fuzzy ways; it is then extremely difficult to remember and correlate all these descriptions in owns head to get a mental picture and understanding of theses concepts and their relationships.
Currently, only some concepts from the "Workflow Management" book by Aalst and Hee (http://www.workflowcourse.com), and their main relationships, have been represented. These concepts are those defined in the first three chapters of the book and presented in italics when first introduced. The terminology of this book follows the one used by the Workflow Management Coalition. We assume that each of those terms has a unique meaning, at least in this page (that is, each term can be used as a concept identifier).
This page will progressively be complemented by other concepts and relations coming from other parts of the book and other sources.
The classic ontological distinctions of "processus" (action, ...), "agent" (people, organization or software agent) and "tool" (software, method, ...) have been followed. However, in the Workflow Management domain, no explicit distinction is made between such entities and "descriptions of such entities". Hence, the distinction is not made below either even though this is incorrect from an ontological viewpoint.
The notation that is used below follow the schema "CONCEPT1 RELATION1: CONCEPT2 (AUTHOR1);" which can be read "AUTHOR1 has entered the fact that 'any CONCEPT1 may have for RELATION1 one or many CONCEPT2'". (Have a quick look below for some examples). It is recommended to use a singular noun (not a verb, nor a plural noun) for the name of a concept or a relation. Here is more complex but still generic example to illustrate the meaning of the separator "," and of the indentation.
concept1
relation1: concept2 (author1) concept3 (author2),
relation2: at least 1 concept5 (author3) concept6 (author4),
relation3: concept7 (author5), //"some comment here"(author7)
relation4: "some informal statement here"(author8) concept8 (author9),
relation5: {concept9 concept10 concept11}(author10) concept12 (author11);
It is read as follows. Any concept1 may have for relation1 one or many concept2 (this has been entered by author1) and may have for relation1 one or many concept3 (this has been entered by author2). Any concept1 has for relation2 at least 1 concept5 (this has been entered by author3) and may have for relation2 one or many concept6 (this has been entered by author4). Any concept1 may have for relation3 one or many concept7 (this has been entered by author5); a comment on this is "some comment here" (comment entered by author7). Any concept1 may have for relation4 "some informal statement here" (this has been entered by author8) and may have for relation4 one or many concept8 (this has been entered by author9). Any concept1 may have for relation5 one or many of the exclusive concepts concept9, concept10 and concept11 (this has been entered by author10) and may have for relation5 one or many concept12 (this has been entered by author11).
The statements below illustrate 1) how statements about already introduced concepts should be indented, 2) how lines can be wrapped so that this file can be printed correctly with a 12 point font. They also also illustrates some common kinds of relationships that should be re-used whenever possible. If not, new kinds of relationships can be invented (but singular nouns should still be used to name them). For normalization purposes, it is recommended to use "synonym" even when "acronym" would seem more appropriate.
workflow
synonym: business_process (pm) WF (pm) BP (pm);
WF_modeling
parameter: WF_theory (pm),
object: workflow (pm);
workflow_management
synonym: WFM (pm),
part: WF_modeling (pm) WF_execution (pm),
tool: WFMS (pm),
object: workflow (pm);
knowledge_acquisition
part: knowledge_acquisition (pm) knowledge_enrichment (pm)
knowledge_distribution (pm),
object: knowledge (pm);
business_process_redesign
synonym: business_process_reengineering (pm) BPR (pm),
method of: "improving the effectiveness and efficiency of BPs" (pm),
agent: organizational_expert (pm) business_expert (pm) IT_person (pm)
business_unit (pm),
part: establish_the_objective_of_the_process (pm)
ignore_the_existence_of_resources_when_definining_a_process (pm)
whenever_possible_make_one_person_responsible_for_a_case (pm)
check_the_need_for_each-tack (pm) consider_the_scope_of_tasks (pm)
strive_for_the_simplest_possible_process (pm)
weigh_a_generic_process_versus_several_versions_of_a_same_process (pm)
weigh_specialization_versus_generalization (pm)
whenever_possible_try_to_achieve_parallel_processing_of_tasks (pm)
investigate_new_opportunities_opened_up_by_technical_progress (pm)
treat_geographically_scattered_as_if_they_are_centralised (pm)
allow_a_resource_to_practise_its_specialty (pm)
whenever_possible_allow_a_resource_to_perform_similar_tasks_in_succession(pm)
try_to_achieve_as_much_flexibility_for_the_near_future (pm)
allow_a_resource_to_work_as_much_as_possible_on_the_same_case (pm);
enactement
part: triggering (pm) actual_performance_of_a_process (pm);
triggering
object: trigger (pm);
actual_performance_of_a_process
specialization: activity (pm);
activity
informal_definition: "a work_item actually performed by a resource"(pm),
performance of: 1 work_item (pm),
performer: at least 1 resource (pm);
assignment
synonym: order (pm),
source: principal (pm),
destination: contractor (pm);
negotiation
object: contract, //"a contract specifying a process"(pm)
method: communications_protocol (pm),
description: contract_tree (pm);
management
specialization: {real-time management operational_management
tactical_management strategic_management}(pm),
part: planning (pm) control (pm) solving_decision_problems (pm),
method: planning_and_control_cycle (pm),
//"using reports to revise objectives, preconditions and decisions"(pm)
agent: management_system (pm);
solving_decision_problems
specialization: definition (pm) creation (pm) evaluation (pm)
selection (pm);
operational_management
example: production_scheduling (pm) train_routing (pm);
tactical_management
specialization: capacity_planning (pm)
budgeting_for_operational_management (pm);
strategic_management
object: structural_aspects_of_processes_and_types_of_resources;
work
specialization: working_on_a_case (pm);
working_on_a_case
informal_definition: "a unit of work that can be distinguished from
all others"(pm),
example: baking_bread (pm) making_a_bed (pm) designing_a_house (pm),
object: 1 case (pm);
procedure
informal_definition: "a generic piece of work; can be seen as the description
of activities"(pm),
specialization: process (pm);
process
informal_definition: "a procedure for a particular case type"(pm),
synonym: workflow (pm) network_of_task (pm)
specialization: business_process (pm) project (pm)
{primary_process secondary_process tertiary_process} (pm),
performer: resource (pm),
part: process (pm), //"a process may or may not have sub-processes"(pm)
//"a (sub)process which does not have sub-processes
// is a task"(pm)
description: at least 1 condition (pm) process_diagram (pm),
//"both the process_diagram and the conditions associated to some processes
// determine the order in which the processes are executed"(pm)
object: at least 1 case (pm),
characteristic: complexity; //"the higher the tasks depends on the case,
// the higher the complexity"(pm)
primary_process synonym: production_process (pm);
secondary_process synonym: support_process (pm);
tertiary_process synonym: managerial_process (pm);
project
informal_definition: "a process for only one case"(pm),
object: 1 case;
task
synonym: atomic_process (pm) logical_unit_of_work (pm),
informal_definition: "when a process is considered indivisible by an actor,
in the eye of this actor, it is a "task": this actor does not see or care
about the possible decomposition of the task into sub-processes;
if a task is not performed entirely by a resource, a rollback may have to
be done by the resource so that the task can be performed again;
a task can be performed by several resources but only one is responsible
for it"(pm),
specialization: work_item (pm),
{manual_task automatic_task}(pm) semi-automatic_task (pm),
example: typing_a_letter (pm) stamping_a_document (pm),
responsible_agent: 1 resource (pm),
parameter: knowledge (pm);
work_item
informal_definition: "a task for a particular case"(pm);
process_diagram
part: routing_structure (pm);
routing_structure
specialization: sequence_structure (pm) selection_structure (pm)
parallelisation_structure (pm) synchonisation_structure (pm)
iteration_structure (pm);
parallelisation_structure
synonym: parallel_routing (pm) AND-split (pm);
selection_structure
synonym: selective_routing (pm) OR-split (pm);
synchonisation_structure
synonym: conditional_routing (pm) OR-join (pm);
Workflow_Management_Coalition
synonym: WFMC (pm),
goal: "developing standard terminology and standard interfaces
for WFMS components" (pm);
actor
informal_definition: "one or several person(s) or machine/program(s) assigning
or performing a process",
specialization: principal (pm) contractor (pm) manager (pm) system (pm)
business_unit (pm),
agent of: negotiation (pm),
characteristic: role (pm); //"role or function"(pm)
principal
informal_definition: "an actor that gives an assignment"(pm),
specialization: boss (pm) customer (pm);
boss
specialization: manager (pm);
manager
specialization: functional_boss (pm) case_manager (pm),
characterics: span_of_control (pm);
resource
synonym: contractor (pm),
informal_definition: "an actor accepting an assignment"(pm),
specialization: co-maker (pm) outsourcer (pm),
member of: resource_class (pm);
resource_class
specialization: role (pm) organizational_unit (pm);
system
informal_definition: "people, machine or computerized information system
carying out particular processes"(pm),
//"system seems a specialization of agent but I am not sure
// of the difference"[pm]
specialization: management_system (pm) managed_system (pm),
part: management_system (pm) managed_system (pm),
part of: managed_system (pm);
managed_system
specialization: enactement_system (pm);
business_unit
informal_definition: "agent producing a limited range of product
in an efficient way"(pm);
organizational_structure
specialization: hierarchical_organization (pm) matrix_organization (pm)
network_organization (pm);
hierarchical_organization
part: capacity_group (pm) functional_department (pm)
process_department (pm) production_department (pm),
description: organizational_chart (pm);
network_organization
synonym: virtual_organization (pm);
information_system
synonym: IS,
generalization: software (pm),
specialization: workflow_management_system (pm) computer (pm)
office_IS transaction-processing_system control_system
knowledge_management_system decision_support_system;
workflow_management_system
synonym: WFMS (pm),
purpose: "insuring that the right information reaches the
right agent (person or computer application) at the right time" (pm),
not purpose: "performing any task in a process" (pm);
//"hence, application software is usually also needed" (pm)
transaction-processing_system
specialization: interorganizational_IS;
WF_theory
specialization: Petri-net_theory (pm),
object: Petri-net;
Petri-net
part: place (pm) transition (pm) token (pm);
place
specialization: input_place (pm) output_place (pm);
transition
specialization: enabled_transition (pm);
token
part: time_stamp (pm);
knowledge
specialization: {tacit_knowledge explicit_knowledge}(pm);
case
synonym: product (pm),
informal_definition: "the particular object of a work;
example: an insurance claim that is about to be handled;
each case has a unique identity that permits to refer to it;
a case has a lifetime (see case_state)"(pm)
description: case_state (pm);
description
specialization: case_state (pm) case_attribute (pm) case_condition (pm)
procedure (pm);
case_type
informal_definition: "a category of cases"(pm),
member: at least 1 case (pm),
characteristic: case_attribute (pm);
case_state
informal_definition: "a description of the case betweeen its appearance and
disappearance"(pm),
part: case_content (pm) at least 1 case_attribute (pm)
at least 1 case_condition (pm);
case_condition
synonym: phase (pm);