JP3846474B2 - Workflow support system - Google Patents

Description

  The present invention relates to a workflow support system that supports a workflow in a distributed environment in which a plurality of information processing apparatuses are connected by a network.

Although the notation of rules for what is called a workflow system varies from system to system, each work (task) corresponds to the editing work of the e-mail document delivered to each user, and the sequential delivery route based on the dependence of the work Generally, rules are defined in a form that defines.
In general, such rules are written by experts using a dedicated development tool for rule definition. However, especially when defining rules for workflows that span a wide area, such as across departments, the entire information It is necessary to investigate and analyze the flow of the product, and to design it while maintaining its consistency.

On the other hand, as a system that can achieve the same effect as defining rules for a wide-area workflow by simply defining rules for neighbors in each department or individual without grasping the overall workflow, The invention disclosed in Kaihei 8-101817 is known.
In this system, tasks generated by distributed and independently defined rules, and tasks generated manually without any rules in the first place are linked as a result, and a large workflow in a wide area is realized. Then, it is possible to follow the flow as if a rule for a large workflow in a wide area was given in advance, and it is possible to obtain the execution status of the related task and the result information of the task execution.

In other words, the conventional workflow rules are determined at the top and given to the top down, even though they are devised in line with the actual situation, whereas they are shown in JP-A-8-101817. In addition to this, bottom-up rules can be defined in the system.
In reality, the way of working is given from the manager to the top-down, or improved to the bottom-up in the field. Therefore, it is a great advantage to be able to define rules from both top-down and bottom-up in this way.

Here, in the case of a system in which rules are always given only top-down, all rules can be centrally managed, so that a simulation tool or the like for checking the overall operation can be prepared in advance. However, the method of distributing rules as in the system disclosed in JP-A-8-101817, for example, has the flexibility to allow bottom-up improvements for each department, but cannot perform prior operation confirmation. was there.
In any case, the way of working changes over time, but since the system does not provide a way to know it, the way of doing the work and the recognition of the top manager There was also a problem that a gap occurred between the two.

The present invention has been made in view of the above-described circumstances, and an object thereof is to enable a simulation to be performed even when rules exist in a distributed manner so that a user can be informed of possible actions in advance. .
Another object of the present invention is to make it possible to automatically detect and notify a user when a work method deviating from an initially recognized work method has increased. .

In the workflow support system on a distributed system connected by a network, the present invention stores rules defining the relationship between a requested task and a partial task for executing the requested task, for example, a plurality of rules for each department. The information of each task stored in the means and executed in the workflow is stored in the history storage means as a task history, and the connection information between the task histories is stored in the task connection information storage means. Then, for each task history stored in the history storage means, it is verified whether the rule compliance determination means complies with the rules stored in the rule storage means.
Therefore, it is possible to determine whether each task is performed in accordance with a presumed work method or whether it deviates.

Further, in the workflow support system according to the present invention, the rule storage means has means for holding the classification attributes of the stored rules, and the rule compliance determination means limits the rules to be referred to within a specific classification attribute range. Perform verification processing.
Therefore, it is possible to perform appropriate verification processing by limiting a set of work methods assumed in advance.

Further, in the workflow support system according to the present invention, the number of task histories determined not to comply with the rule by the rule compliance determination unit is a predetermined ratio with respect to the total number of task histories stored in the history storage unit. When it exceeds, it has a user interface for notifying the user of the ratio.
Therefore, the user can know in a timely manner that the ratio of the action deviating from the work method assumed in the organization has exceeded a certain threshold.

The present invention also provides a plurality of rule storage means for storing rules defining the relationship between a requested task and a partial task for performing the requested task in a workflow support system on a distributed system connected by a network. And a plurality of rule interpretation execution means for performing the requested task by applying the rules. Then, when a task request having a simulation attribute is received, the virtual rule expansion unit generates information on a task request newly generated when a rule is applied, instead of passing the request to the rule interpretation execution unit. To the request source of the task request having the simulation attribute.
Therefore, the end user can also simulate how the task activated by the user is processed and how the task affects the organization according to the actual rules at that time.

Further, in the workflow support system according to the present invention, the virtual rule expansion means performs the rule expansion simulation within the range of the number of times designated by the user.
Therefore, the simulation range can be limited as necessary.

The present invention also provides a plurality of rule storage means for storing rules defining the relationship between a requested task and a partial task for performing the requested task in a workflow support system on a distributed system connected by a network. And a plurality of rule interpretation execution means for performing the requested task by applying the rules. When the task request is received, the anticipation rule expanding unit assigns an anticipation attribute to a new task request that is sequentially generated when the rule is applied before passing the request to the rule interpretation execution unit. The task arrival prediction display user interface displays the task request having these prediction attributes to the user.
Therefore, the user can know in advance a task request that will be arriving in the near future, and can easily plan work.

As described above in detail, according to the present invention, simulation can be performed even when rules exist in a distributed manner, and the user can know in advance the possible actions. Moreover, since each user can know the work to come from now on, it becomes easy to adjust the schedule.
In addition, when the way of working that deviates from the way of work that was recognized at the beginning increases, it is automatically detected, so that all users including managers have changed their work forms. Can know.

The workflow support system of the present invention will be specifically described with reference to an embodiment.
FIG. 1 shows the configuration of a first embodiment of a workflow support system using a distributed system connected by a network.
The workflow support system according to the present embodiment stores a task request reception database 1 that holds a request for performing a task received via a network, stores information on each task that has been performed as a task history, and connection information between the task histories. Stored in the task history / task connection database 2, the workflow rule base 3 storing rules defining the relationship between a task and a partial task for executing the task, and the task history / task connection database 2 And a rule conformity determination processing unit 4 that verifies whether the task history conforms to the rules stored in the workflow rule base 3. Note that at least the rule base 3 is provided in a distributed manner, for example, for each department, and a local rule can be set for each department.

Furthermore, this workflow support system has various user interfaces distributed on the network, and receives a reference instruction from the user for information stored in the task history / task connection database 2, a task reference user interface 5; A rule classification / deviation rate notification user interface 6 for receiving a classification used in the verification process from the user and displaying and displaying the result of the verification process to the user.
In the present invention, the configuration of the workflow support system is arbitrary. In short, in order to perform a task requested in any terminal on the network, the partial task is performed in any other terminal on the network. Should be carried out.

Next, the processing operation by the above-described workflow support system will be described using a workflow for article purchase processing as an example.
A person who wants to purchase goods first describes a purchase slip, asks the purchasing department after obtaining approval from the superior, and reports confirmation after delivery. Suppose that it is decided in the center and given top-down.
The notation method of the rule of what is called a workflow system varies depending on the system, but in this example, description will be made using the notation method described in JP-A-8-101817. In this notation, the above workflow rules can be defined as follows.

Article purchase processing (? Requester, accounting department,? Purchase slip) ←
Purchase slip creation (? Requester,? Requester,? Purchase slip),
Approval processing (? Requester,? Superior,? Purchase slip),
Order request (? Requester, purchasing department,? Purchase slip),
Delivery confirmation report (? Requester, accounting department,? Purchase slip).

Here, the first argument represents the performer, the second argument represents the requester (also a report destination), and the third and subsequent arguments represent information or electronic documents to be exchanged and stored or their storage locations. Also,? Indicates a variable. It is important that the variable names in this rule indicate the relationship that the same name should have the same value, and the name itself may be discarded after the rule is applied.
← indicates an implication (if it is ~). That is, a ← b, c is a if b and c. Procedural interpretation of this proof process by backward reasoning requires that both b and c must be achieved in order for a to be achieved (proven), and therefore the task of a must be activated (which must be achieved) If this occurs, the tasks b and c are started. In addition, b and c are allowed to be executed simultaneously (in parallel).

Now, suppose that Mr. A, who is supervised by Mr. Y, has performed this processing. That is, it is assumed that the task “article purchase processing (A, accounting department, information storage area 1)” occurs as a goal.
When this task is received, the task information is registered in the table of the task management database (task history storage unit) 2 as shown in FIG. Here, only the minimum items related to the present invention are shown in the task information. That is, for the task “article purchase processing (A, accounting department, information storage area 1)”, the task ID is “02000”, the task name is “article purchase processing”, the execution state is “running”, and the performer is “A” "Accounting department" as the report destination, and "Information storage area 1" indicating the storage location of the actual data as item 1 are registered.

  By registering the task information in the table in this way, the rules stored in the rule base 3 can be applied to the execution of the task, and this workflow is started, and the requested task (parent task) as a goal is set. A partial task (child task) to be executed is newly generated as follows.

Purchase slip creation (A, A, information storage area 1),
Approval process (A, Y, information storage area 1),
Order request (A, purchasing department, information storage area 1),
Delivery confirmation report (A, accounting department, information storage area 1).

When these child tasks are also accepted, they are added to the task table of the task management database 2 as shown in FIG.
Here, in the case of a newly generated task, a unique value that has not yet appeared on the network is generated and assigned. A unique value on the network can be easily generated by combining an address uniquely indicating this environment on the network and a unique value on the environment.

Further, ← (implication) on the applied rule is stored in the process table (task connection information storage means) of the task management database 2 as shown in FIG. 4 as a parent-child relationship between tasks.
As described above, when there is a rule applicable to the requested task, a rule interpretation execution unit (not shown) identifies a child task for performing the requested task according to the rule. The task is registered in the task table, and the connection relationship between the parent task and the child task is registered in the process table.

Now, it is assumed that the way of processing changes with the passage of time. For example, it is assumed that the purchase requester creates a purchase slip and writes the planned expenditure amount in the budget management table in the department. In other words, it was not decided to change the rule at the top, but only a certain department redefined the local rule, and the number of people who do different processing manually without following the rule will gradually increase Suppose a phenomenon occurs. For example, not only when a local rule is used but also when a user manually adds a task arbitrarily, data is accumulated in the task management database 2 in the same manner as when a rule exists. Will be.
Accordingly, data as shown in FIGS. 5 and 6 is stored in the task table and the process table due to the change in which the task of “budget management table entry” is added.

In response to the change as described above, the rule compliance determination unit 4 operates according to the procedure shown in FIG. 8 according to an instruction from the user, a preset timing, and the like, and the data stored in the task management database 2 is changed to the rule base. 3 is verified whether it conforms to the rules stored in 3.
Note that the following rules shown above are stored in the rule base 3 as they are. Each rule is given a unique ID, and the classification attribute relating to the rule is preset and stored in the rule classification attribute table of the rule base 3 as a pair with the rule ID as shown in FIG. .

Article purchase processing (? Requester, accounting department,? Purchase slip) ←
Purchase slip creation (? Requester,? Requester,? Purchase slip),
Approval processing (? Requester,? Superior,? Purchase slip),
Order request (? Requester, purchasing department,? Purchase slip),
Delivery confirmation report (? Requester, accounting department,? Purchase slip).

First, by referring to the rule classification attribute table, a set of rule IDs used for rule compliance verification is obtained within a range of classification attributes specified by the user, a rule having these IDs is extracted, and a database for verification processing (rules) The data is stored in the memory area used by the compliance determination unit 4 (step S1). Here, it is assumed that only the company-wide standard (rule ID is “07001”) is specified, and the rule set has only one element.
As a result, the above rules stored in the rule base 3 are extracted as a rule set as described below.

Article purchase processing (? Requester, accounting department,? Purchase slip) ←
Purchase slip creation (? Requester,? Requester,? Purchase slip),
Approval processing (? Requester,? Superior,? Purchase slip),
Order request (? Requester, purchasing department,? Purchase slip),
Delivery confirmation report (? Requester, accounting department,? Purchase slip).

Then, task histories are taken out one by one from the top of the task table (step S2). In this example, it is assumed that the top is the record shown in FIG.
Next, the task ID “03000” is acquired from this task history (step S3), and the child task of the task whose task ID is “03000” (that is, the record having 03000 as the parent) is shown in FIG. It is obtained by referring to the process table (step S4).
Next, it is confirmed that these child tasks exist (step S5), and a task history corresponding to the acquired child task ID is acquired from the task table (step S6).

Then, from the history of the parent task and the child task, the task name is set as a predicate name, the necessary fields are arranged as arguments, and each is converted into the following predicate expressions (step S7).
That is, the parent task is “article purchase processing (A, accounting department, information storage area 1)”, the child task is “purchase slip creation (A, X department, information storage area 1)”, “budget management table entry ( A,? Requester, information storage area 1) "," Approval process (A,? Supervisor, information storage area 1) "," Order request (A, Purchasing department, information storage area 1) "," Delivery confirmation report (A, accounting department, information storage area 1).

Next, the predicate obtained from the child task is stored as a theorem in the database for the above verification process (step S8), and the predicate obtained from the parent task is used as a goal to perform a verification process to check whether the rule is compliant (step S8). S9). That is, it is verified whether the predicate of the parent task can be proved from the rule set that is an inference rule and the set of predicates of the child task that is an axiom or theorem.
This proof processing can be calculated, for example, based on first-order predicate logic having a closed world hypothesis (negative due to failure) by performing backward inference in the same manner as in the Prolog language using the SLD rebuttal method. That is, the calculation can be performed by giving the predicate of the parent task as a goal in a state where only the rule set and the set of child task predicates are asserted.

Then, if it cannot be proved by this process (step S10), it is determined that all the tasks appearing here do not comply with the rule (step S11), and the process for the next task history is performed. This is performed (step S15).
On the other hand, if it can be proved, it is further investigated whether all axioms or theorems have been used for the proof (step S12). In this investigation process, for example, when an axiom or a theorem is used in the proof process, a mark is made, and it is only necessary to refer to whether all are marked later. Every time a proof is completed, all marks are deleted for the next time.

As a result of the above investigation, if all axioms or theorems are used, it is determined that all the tasks appearing here comply with the rules (step S13), and if all are not used. Forcibly backtracking and searching for another certification path is repeated (step S14). In addition, when such a repetitive process is performed and there are no more certification paths, it is determined that all the tasks appearing here are not compliant with the rule (step S11).
The above process is repeated for all the records of the task history (steps S15 and S16), and the verification result is notified to the user through the user interface 6.

Although notification to the user can be performed by various methods, in this embodiment, the deviation rate for the rule is notified to the user.
This deviation rate can be obtained by calculating (number of records of tasks that do not conform to the rule) / (number of all records in the task history) × 100. The user can recognize whether or not the rule has been deviated.

  For example, when a rule set is first determined with a company-wide standard classification attribute, and the deviation rate exceeds a certain threshold, it indicates that the work method assumed as a standard is no longer suitable for the actual situation of the organization. Should be interpreted. Therefore, in this embodiment, the user sets a predetermined threshold value in the user interface 6, and when the threshold value is exceeded, a warning or deviation rate is displayed to the user. This allows managers to know when to decide whether to confirm another order that has naturally occurred from the bottom up or to design a new way of working.

FIG. 11 shows the configuration of a workflow support system according to the second embodiment of the present invention.
Since the end user sometimes wants to grasp to some extent how the task he / she started will be processed thereafter, the workflow support system of this embodiment has a virtual rule expansion means for realizing this. Yes.

  That is, in addition to the configuration of the first embodiment described above, this workflow support system applies a rule to the simulation request reception database 7 that holds a task request having a simulation attribute issued by a user and the requested task. A plurality of rule interpretation execution processing units 8 to be executed and tasks newly generated when a rule is applied instead of passing the request to the rule interpretation execution processing unit 8 when a task request having a simulation attribute is received It has a virtual rule expansion processing unit 9 that generates request information and returns it to a request source of a task request having a simulation attribute, and a simulation execution user interface 10 that outputs a simulation result to the user.

Next, virtual rule expansion processing mainly performed by the virtual rule expansion processing unit 9 in the present embodiment will be described.
In the following description, it is assumed that the following rules are already stored in the rule base 3 as in the first embodiment.

Article purchase processing (? Requester, accounting department,? Purchase slip) ←
Purchase slip creation (? Requester,? Requester,? Purchase slip),
Approval processing (? Requester,? Superior,? Purchase slip),
Order request (? Requester, purchasing department,? Purchase slip),
Delivery confirmation report (? Requester, accounting department,? Purchase slip).

Here, actually starting the article purchase processing task is to give this task as a goal to be proved. Therefore, tasks on the right side of the rule (execution sequence on the right side of the implication symbol) are also sequentially activated by the rule interpretation execution processing unit 8, and child tasks are expanded. These tasks reach the agenda (mailbox or ToDo list) of the task request reception database 1 of each user, and if accepted, are stored as a history in the task table of the database 2 and can be referred to by the user through the user interface 5. Become.
However, in this embodiment, when the user designates the simulation through the user interface 10, the attribute indicating the simulation and the number of times of applying the rule are given to the goal [Product purchase processing (A, accounting). Section,? Purchase slip), simulation, twice, and so on.

When the received goal has the simulation attribute as described above, the goal is not stored in the agenda (mailbox or ToDo list) and task table to which the user refers, and the task interpretation by the rule interpretation execution processing unit 8 is performed. Without starting, the virtual rule expansion processing unit 9 performs only the expansion according to the rule in parallel. Then, all the developed tasks are assigned simulation attributes in the same manner, and the number of rule application is reduced by 1 and transferred.
In this process, if a rule to be applied is not found or the rule application count becomes 0, the expanded result is returned to the request source. In addition, in the virtual rule expansion processing unit 9 of the environment that has received the result, if there is a further request source, the received result and the result of expansion of the environment itself are collectively returned to the request source.
By such processing, information on how the task started by the user is developed according to the rule is returned to the user who requested the simulation and notified through the user interface 10.

FIG. 12 shows the configuration of a workflow support system according to the third embodiment of the present invention.
Since the user sometimes wants to grasp in advance what kind of task will arrive, the workflow support system of the present embodiment has a prediction rule expansion means for realizing this.

  In other words, in addition to the configuration of the first embodiment described above, this workflow support system includes a plurality of rule interpretation execution processing units 8 that execute a requested task by applying a rule, and a prediction attribute issued by a user. Predictive task request reception database 11 that holds task requests, and new task requests that are sequentially generated when a rule is applied before the request is passed to rule interpretation execution processing unit 8 when the task request is received A prediction rule expansion processing unit 12 for generating a parallel request by assigning a prediction attribute to a task arrival prediction display user interface 13 for displaying a task request having the prediction attribute.

Next, task arrival prediction processing mainly performed by the prediction rule expansion processing unit 12 in this embodiment will be described.
In this embodiment, when the first task is started by the user, in addition to the transfer of the task goal as in the prior art, the predicted attribute and the ID of this task are used instead of the simulation attribute shown in the second embodiment. The assigned tasks such as [article purchase processing (A, accounting department,? Purchase slip), forecast, task ID: 03000] are transferred.

If the received goal has the prediction attribute as described above, the prediction rule expansion processing unit 12 does not store the goal in the agenda (mailbox or ToDo list) referred to by the user and in the task table. Stores in a separate arrival prediction table. Then, the prediction rule expansion processing unit 12 expands the rules in parallel, assigns the prediction attribute to all the expanded tasks in the same manner, inherits the task ID as it is, and assigns and applies the applied rule ID. For example, if the ID of the previous rule is 07001, tasks such as [purchase slip creation (A, A,? Purchase slip), forecast, task ID: 03000, rule ID: 07001] are transferred.
If no rule to apply is found, the process ends there.

As a result of such processing, a task that is expected to arrive is stored in the arrival prediction table of the corresponding user, so that the user can know in advance the task that will arrive from now on by referring to this through the interface 13.
Here, in reality, there is no case where another rule is selected in the middle of the process. Therefore, the expected rule expansion processing unit 12 of this embodiment also has a function of performing the following deletion process.

That is, for a goal that has inherited the first task ID, the ID of the rule that is about to be applied is acquired, and the task IDs match but the rule ID is one by referring to the arrival prediction table. If not, it is determined that a rule different from the prediction has been selected, and the data related to the prediction is deleted.
Specifically, a task having an expected deletion attribute such as [purchase slip creation (A, A,? Purchase slip), predicted deletion, task ID: 03000, rule ID: 07001] is transferred.

When a task having such an expected deletion attribute is received, each environment deletes the corresponding information from the arrival prediction table, and this deletion task is similarly developed according to the rule.
At the same time, when another rule is applied as described above, a task having a predicted attribute to which the rule ID is newly assigned as an attribute is transferred.
By such processing, the expected contents are corrected in accordance with the actual rule selection, and the user can accurately grasp what task arrives.

1 is a configuration diagram of a workflow support system according to a first embodiment of the present invention. It is a figure which shows an example of a task table. It is a figure which shows an example of a task table. It is a figure which shows an example of a process table. It is a figure which shows an example of a task table. It is a figure which shows an example of a process table. It is a figure which shows an example of a rule classification attribute table. It is a flowchart which shows the process sequence which concerns on 1st Example of this invention. It is a figure which shows an example of a task table. It is a figure which shows an example of a task table. It is a block diagram of the workflow assistance system which concerns on 2nd Example of this invention. It is a block diagram of the workflow assistance system which concerns on 3rd Example of this invention.

Explanation of symbols

2 ... Task history / task connection database,
3 ... Workflow rule base,
4 ... Rule compliance determination processing unit,
6 ... Rule classification / deviation rate notification user interface,
8: Rule interpretation execution processing unit,
9: Virtual rule expansion processing unit,
10 ... Simulation execution user interface,
12 ... Anticipation rule expansion processing unit,
13 ... Task arrival prediction display user interface,

Claims (1)

In a workflow support system on a distributed system connected by a network,
A plurality of rule storage means for storing rules defining a relationship between a requested task and a partial task for performing the requested task;
When a request task having a prediction attribute is received, the task identifier and the prediction attribute of the request task and the rule identifier of the applied rule are assigned to the partial task generated when the rule is applied, and stored in the arrival prediction table. Prediction rule expansion means for performing task arrival prediction processing ;
A user interface that allows a user to refer to the partial task stored in the arrival prediction table ,
In the task arrival prediction process, the prediction rule expansion unit is configured to receive a partial task to which a rule identifier different from a rule identifier of a rule to be applied and a task task having the same task identifier as the request task for performing the task arrival prediction process is provided. If already stored in the prediction table, an expected deletion attribute for assigning the task identifier and rule identifier of the already stored partial task and deleting the already stored partial task from the arrival prediction table Is generated, and the task identifier and the prediction attribute of the request task and the rule identifier of the applied rule are assigned to the partial task generated when the rules having different rule identifiers are applied, and the arrival prediction workflow support system for causing stored in the table

Images