WO2007132581A1 - ワークフローシステム、管理方法、プログラム及び記録媒体 - Google Patents

ワークフローシステム、管理方法、プログラム及び記録媒体 Download PDF

Info

Publication number
WO2007132581A1
WO2007132581A1 PCT/JP2007/053592 JP2007053592W WO2007132581A1 WO 2007132581 A1 WO2007132581 A1 WO 2007132581A1 JP 2007053592 W JP2007053592 W JP 2007053592W WO 2007132581 A1 WO2007132581 A1 WO 2007132581A1
Authority
WO
WIPO (PCT)
Prior art keywords
task
data
workflow
progress
approval
Prior art date
Application number
PCT/JP2007/053592
Other languages
English (en)
French (fr)
Inventor
Kazuko Tatebe
Ryotaro Seno
Junko Hattori
Original Assignee
Panasonic Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corporation filed Critical Panasonic Corporation
Publication of WO2007132581A1 publication Critical patent/WO2007132581A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management

Definitions

  • the present invention relates to a workflow system and the like.
  • a workflow system has been introduced as a means of managing such progress.
  • the workflow system for example, when a project requires approval by a plurality of other people, the above-mentioned plurality of other people are asked for approval using a circulation using a computer network, etc. and approved. The project is allowed.
  • Japanese Unexamined Patent Application Publication No. 2002-24499 discloses a technique that can efficiently circulate approval documents such as approval documents and minutes, via a network.
  • Japanese Patent Laid-Open No. 2002-230249 discloses a technique that allows an authorizer to easily access approval application information.
  • Patent Document 1 Japanese Patent Laid-Open No. 2002-24499
  • Patent Document 2 Japanese Patent Laid-Open No. 2002-230249
  • the period from the start to the end of the project may be long.
  • whether or not the project can be continued is checked as appropriate according to market trends, progress, and budget (financial status).
  • approval is not obtained, the project will be canceled, for example.
  • a high-ranking approver eg, president
  • a workflow with low importance and a workflow with high importance are uniformly determined, that is, it is easily determined to continue even with a workflow with high importance.
  • the present invention has been proposed on the basis of the above-described conventional circumstances, and an object thereof is to provide a workflow system or the like that realizes an approval process on a workflow based on the latest information. .
  • the workflow system can identify one or a plurality of tasks that can identify the task associated with the scheduled start date data that is the scheduled start date of the task and the scheduled finish date data that is the scheduled end date of the task.
  • a first task information storage means for storing the ID in association with the first workflow ID capable of specifying the first workflow; and receiving input of one or more task IDs and the first workflow ID;
  • the first registration receiving means stored in one task information storage means and the update of progress record data indicating the progress of the task progress are received, and the first task information store is associated with the task ID of the task.
  • the progress accepting means stored in the means, the approval task ID that can identify one or more approval tasks for approving the continuation of the first workflow, and the second workflow Second task information storage means for associating and storing a second workflow ID that can be defined, and receiving the input of one or a plurality of approval task IDs and the second workflow ID, and the second task information storage means Stored in the first task information storage means when receiving the transmission instruction when receiving the transmission instruction of the second registration accepting means and the approval screen data for performing the approval task.
  • the acquisition means for acquiring the scheduled start date data, the scheduled end date data of the one or more tasks, and the updated progress record data, the scheduled start date data and the scheduled end date data acquired by the acquisition means
  • approval screen generation means for generating approval screen data including progress result data.
  • approval can be performed based on the latest information that is not based on the task status at the time of registration of the approval workflow. This is particularly true when the approval workflow is approved by a large number of approvers. Can also be approved based on the latest information.
  • the task stored in the first task information storage means may be an advance task that constitutes an advance workflow for managing the progress of the project.
  • the schedule correcting means further determines whether or not there is a progress task depending on the scheduled end date of the progress task that is the target of output of the correction end date. Then, a new scheduled start date and a new scheduled end date are calculated for the dependent progress task, and are stored in association with the task ID of the dependent progress task as the scheduled modification start date data and scheduled modification end date data.
  • the approval screen generation means generates the approval screen data including the dependent progress status, the correction start date data, and the correction end date data.
  • the schedule correction means compares the scheduled end date with the current date, and calculates the scheduled modification end date only when a predetermined number of days prior to the scheduled end date is satisfied. There is a configuration in which the scheduled date of completion of correction is calculated only when the progress data is smaller than a predetermined threshold.
  • the first task information storage means stores the task ID and the estimated cost data required when performing the work corresponding to the task ID in association with each other, and updates the progress by the advance acceptance means. Based on the progress result data received and the planned cost data, a new planned cost of the task corresponding to the progress result data is calculated as corrected cost data and stored in association with the task ID.
  • the approval screen generation means generates the approval screen data including the correction cost data.
  • the workflow system can be embodied using a computer.
  • each means described above is embodied by operating a program on a computer.
  • the storage means are implemented in HDD (Hard Disk Drive) and various memories.
  • approval can be performed based on the latest information that is not in the task state at the time of registration of the approval workflow.
  • the approval workflow is approved by a large number of approvers.
  • approval processing can be performed based on the latest information.
  • FIG. 1 is a schematic functional block diagram of a terminal, an application server, and a DB server that constitute a workflow system.
  • FIG. 2 is a schematic configuration diagram of an application server.
  • FIG. 3 is a diagram showing a system configuration example of a workflow system.
  • Fig. 4 shows the workflows that make up the project.
  • FIG. 5 is a diagram showing an example of a workflow information table and a task information table.
  • FIG. 6 is a flowchart showing a procedure of schedule correction processing.
  • FIG. 7 is a flowchart showing the procedure of the approval process.
  • FIG. 8 is a diagram showing a first example of an approval screen.
  • FIG. 9 is a diagram showing a second example of an approval screen.
  • FIG. 10 is a diagram showing items added to the task information table.
  • FIG. 11 is a schematic functional block diagram of a workflow system corresponding to Application Example 2.
  • FIG. 12 is a diagram showing an example of an importance determination table and an approver table.
  • FIG. 13 is a diagram showing a third example of an approval screen.
  • FIG. 14 is a diagram showing an example of a task information table in which a new approver is added.
  • the workflow system according to the present invention has a power that allows the terminal 101, the application server 102, and the database server (DB server) 103 to be communicably connected via a network.
  • the location server 102 and the DB server 103 may be provided on the same computer.
  • FIG. 1 is a schematic functional block diagram of a terminal 101 that transmits / receives various data and commands to / from the workflow system 100, and an application server 102 and a DB server 103 that constitute the workflow system 100. Processing and the like will be described later.
  • FIG. 2 is a schematic configuration diagram of the application server 102, which includes a CPU (Central Processing Unit) 201, a RAM (Random Access Memory) 202, a ROM (Read Only Memory) 203, an HDD 204, and a network I / F. (Interface) Connected via 205 force internal nose 206.
  • the CPU 201 operates as each unit shown in FIG. 1 by using, for example, the RAM 202 as a work area and executing a program stored in the ROM 203, the HDD 204, or the like.
  • the network IZF205 is connected to a network and can exchange data with other devices.
  • the configurations of the terminal 101 and the DB server 103 are the same as those of the application server 102, and different processes can be executed because the stored program data is different.
  • FIG. 3 shows a system configuration example of the workflow system 100.
  • a plurality of terminals 101, an application server 102, and a DB server 103 are communicably connected via a network 207 such as the Internet or an intranet.
  • a network 207 such as the Internet or an intranet.
  • the above-mentioned project A401 is based on a project progress workflow 402 composed of planning (task A-1), design (task A-2), and development (task A-3). It is configured so that design can be performed when the planning is completed, and development can be performed when the design is completed.
  • task A-l, task A-2, and task A-3 are progress tasks that constitute the progress workflow that manages the progress of the project.
  • the planning task A-1, the design task A-2, and the development task A-3 are registered in the workflow system 100 as task progress flows 403, 404, and 405, respectively.
  • the person in charge enters new progress data in the task progress workflow 403-405 Furthermore, by updating as needed, it is possible to grasp the progress of each task A-l, A-2, A-3. Note that the input to the above-mentioned progress record data is included in the update of the progress record data in the present application.
  • a project approval workflow 406 is registered in the project A401.
  • the project approval workflow 406 includes approval A (approval task B—1), approval B (approval task B—2), and approval C (approval task B—3).
  • the project approval workflow 406 is a workflow for regularly registering and implementing, for example, a plurality of times until the project A401 is completed, that is, reviewing the project A401.
  • approval of all the above approval tasks B-1 to B-3 allows project A40 1 to continue. This approval task is different from the above advance task in the sense that it requires approval.
  • a user accesses the application server 102 shown in FIG.
  • the user activates predetermined software such as a browser on the terminal 101 using the input means 104 such as a mouse or a keyboard, and enters the address field of the software displayed on the display unit 105 such as a display. This is done by inputting the URL (Uniform Resource Locator) of the application server 102.
  • predetermined software such as a browser on the terminal 101 using the input means 104 such as a mouse or a keyboard
  • the address field of the software displayed on the display unit 105 such as a display. This is done by inputting the URL (Uniform Resource Locator) of the application server 102.
  • URL Uniform Resource Locator
  • Access by the terminal 101 is detected by, for example, the screen generation unit 107 via the transmission / reception unit 106 of the application server 102, and the screen generation unit 107 performs processing provided by the workflow system 100 for the terminal 101.
  • Send a menu (not shown).
  • the transmitted menu is received by the terminal 101 and displayed on the display means 105.
  • the menu displayed on the display means 105 includes an item for registering a new workflow, for example, and the user of the terminal 101 selects the item from the input means 104.
  • the transmission / reception means 106 receives a signal indicating that.
  • the transmission / reception unit 106 determines a signal indicating that the item has been selected, and transmits the signal to the first registration receiving unit 108 corresponding to the processing of the item.
  • “project progress workflow registration” is selected from among a plurality of items constituting the menu.
  • the signal indicating that the “project advance workflow registration” is selected is received by the first registration accepting means 108, and the workflow registration screen data including the input items for project advance workflow registration is displayed. Returned to terminal 101.
  • the returned workflow registration screen data is displayed on the display means 105 of the terminal 101.
  • the workflow registration screen data includes, for example, input items shown in the “workflow information table 5001” in FIG. 5, ie, a draft name 503, a draft date 504, a drafter ID 505, a project ID ID 506, and the like.
  • the user enters, for example, "Project A” as the draft name 503, for example, "2005Z9 Z10", which is the date when the draft date is entered, as the drafter ID. Enter the project ID “xxx” that can uniquely identify the project A that has already been approved for project implementation as the project ID, for example “Register”. Press the “button (not shown).
  • each input data inputted by the user is received by the first registration receiving means 108, and the first registration receiving means 108 receives each input data.
  • the workflow information storage means 109 is provided with the workflow information table 501 shown in FIG. 5, and the input name corresponding to the input data 503, the proposal date 504, the drafter ID 505 Stored in the project ID506.
  • “XX-XXXX” which is a workflow ID 502 that can uniquely specify a new registered workflow, is given by the first registration receiving means 108 and stored in the workflow ID 502.
  • the first registration receiving means 108 described above includes one or a plurality of tasks constituting the new workflow.
  • Task registration screen data for registering a task is transmitted to the terminal 101.
  • the task registration screen data includes, for example, input items shown in “task table A511” in FIG. 5, that is, task ID 513, scheduled start date 514, scheduled end date 515, dependency destination 522, and the like.
  • the user inputs, for example, “planning task A—1,” “design task A—2,” and “development task A—3” as task ID 513.
  • Press the “Register” button Note that the dependee is a task that is assumed to be completed when the task is started.
  • each input data input by the user is received by the first registration receiving means 108, and the first registration receiving means 108 receives each input data.
  • the task information storage means 110 is provided with a task information table A511 shown in FIG. 5, and the input data input corresponds to a task ID 513, a scheduled start date 514, and a scheduled end date. 515 and stored in the dependency destination 522.
  • the workflow ID of the project A is stored in the workflow ID 512 as the workflow ID 512 related to the registered new task ID.
  • the first registration receiving means 108 calculates a scheduled period that is a period from the scheduled start date 514 and the scheduled end date 515 to the end of the task start force, and stores it in the scheduled period 516.
  • the project progress workflow 402 composed of the planning task A-1, the design task A-2, and the development task A-3 shown in FIG. 4 corresponds to the planning task A-1.
  • the task advance workflow 403, the task advance workflow 404 corresponding to the above design task A-2, and the task advance workflow 405 corresponding to the development task A-3 are the workflow information storage means 109 and the task information storage means 110. Registered in
  • the person in charge of the progress management of the planning task A-1 accesses the application server 102 from the terminal 101. Then, for example, “Progress record data input” is selected from the menu, and the task progress workflow 403 corresponding to the planning task A-1 is selected. A signal indicating that the “advance achievement data input” is selected is received by the advance acceptance means 111 via the transmission / reception means 106. Then, the progress receiving means 111 obtains the scheduled start date 514, the scheduled end date 515, the actual start date 519, the actual end date 520, and the progress rate 521 of the above-mentioned planning task A-1 from the task information table A511. And transmitted to the screen generation means 107.
  • the screen generation means 107 proceeds to input progress result data.
  • the progress result data refers to a result start date 519, a result end date 520, and a progress rate 521.
  • the transmitted progress record input screen data is displayed on the display means 105 of the terminal 101.
  • the person in charge inputs the progress rate of work for the scheduled period, taking into account the progress of the day.
  • the input progress rate is overwritten on the progress rate 521 of the task information storage means 110 via the progress rate acceptance means 111, that is, updated. If the date when the work is started is entered, the date is entered on the actual start date indicating the day when the work is actually started. In addition, if it is input on the day when the work of the planning task A-1 is completed, the date is input on the actual end date indicating the actual end of the work, and 100% is input as the progress rate. Based on the input, the result start date 519, the result end date 520, and the progress rate 521 of the task information table A511 are updated, that is, the input is reflected.
  • the daily work performance of each task is reflected in the task progress workflows 403 to 405.
  • the design task A-2 task advance workflow 404 that depends on the task, and the workflow system On 100, it is possible to input / update the progress rate of the design task A-2.
  • the schedule correction means 112 provided in the application server 102 performs the schedule correction processing, for example, at a time determined every day.
  • the schedule correction process is performed as follows.
  • the schedule correction means 112 constituting the application server 102 is scheduled to start for each target task (here, planning task A-l, design task A-2, development task A-3). Date 514, scheduled end date 515, scheduled modification end date 518, scheduled period 516, and actual end date 520 are acquired ( Figure 6: S601).
  • a task that has not yet been completed that is, a task for which the actual end date 520 has not been input
  • it is determined whether or not the current date is a predetermined number of days before the scheduled end date 515 (Fig. 6: S602). For example, if it is determined based on the contents stored in the task information table A511, the date for the planning task A-1 has already been entered in the actual end date 520 and the progress rate 512 is 100%.
  • the schedule correction process ends without making a determination (FIG. 6: S602 No ⁇ End).
  • design task A-2 does not finish because the date is not entered in the actual end date 520, and the current end date is compared by comparing the expected end date 515 (2005ZlOZ31) with the current date. It is determined whether it is a predetermined number of days before the scheduled date 515 (Fig. 6: S602). However, if a date is entered in a scheduled modification end date 518 described later, the scheduled modification end date 518 is compared with the current date and time instead of the scheduled termination date 515.
  • the target The progress rate 521 (here 25%) of the task (design task A-2) is acquired (Fig. 5: S6 03). Then, it is determined whether or not the progress rate is equal to or less than a predetermined value (here, 50%) (FIG. 6: S604).
  • a predetermined value here, 50%
  • the progress rate is below the specified value, it means that the progress rate is low even though the planned end date is close, and the current end date (or planned end date) will be the end of the work. Is determined to be difficult.
  • the schedule correction means 112 calculates a new scheduled end date for the design task A-2 based on the progress rate 521 out of the progress results received by the progress reception means 111. Then, it is stored in the scheduled modification end date 518 as the scheduled modification end date.
  • the scheduled date of completion of correction is calculated, for example, as follows. That is, first, the design task A- acquires second date range 516 "21 days", which current proceeds from 100% ⁇ 5 21 "25 0/0" bow
  • ⁇ was the value "75 0/0 "Multiply. From this [21 X 0.75 15.75 (rounded up to 16 days) is the extended number of days. From the actual start date 519 "2005Z10Z12", “2005/11 Z17" 37 days (including the current day) after calculating the extended number of days "16 days” and the planned period 516 "21 days” will be calculated as the scheduled end date. (Fig. 6: S605). The calculated value is stored in the scheduled modification end date 518 corresponding to design task A-2.
  • the schedule correction unit 112 determines whether or not there is another task that depends on the design task A-2, that is, the scheduled end date of the design task A-2.
  • Figure 6 S606
  • Design task A-2 is stored in the dependency destination 522 of development task A-3 in task information table A511
  • development task A-3 that depends on the scheduled end date of design task A-2 Exists. If there is, add the above extended number of days “16 days” to the scheduled start date “2005Z11Z01” (or the scheduled modification start date if revision scheduled start date 517 is already entered) for the dependent task.
  • the date “2005Z11Z 16” is calculated as the scheduled start date of correction.
  • a date obtained by adding the scheduled period 516 “30 days” to the scheduled correction start date is calculated as the scheduled correction end date 518.
  • the calculated value is the scheduled modification start date 517 corresponding to development task A-3 in task information table A511 and It is stored in the scheduled end date 518.
  • the scheduled start date and the scheduled end date of the task (development task A-3) corresponding to the task whose design end date has been changed (design task A-2) are also scheduled to start and modify. It is corrected as the scheduled end date.
  • Table power after correction according to the above processing example is the task information table A511 shown in FIG.
  • the menu displayed on the display means 105 includes an item for registering a new workflow for approval.
  • a user who wants to register a workflow for approval selects the item using the input unit 104, and a signal indicating that is received by the transmission / reception unit 106.
  • the transmitting / receiving unit 106 determines a signal indicating that the item has been selected, and transmits a signal indicating that the item has been selected to the second registration receiving unit 113 corresponding to the processing of the item.
  • the displayed approval workflow registration screen includes, for example, input items shown in "workflow information table 501" in FIG. 5, that is, draft name 503, draft date 504, drafter ID 505, project ID 506, and the like. .
  • the user sets, for example, "2005 Z10Z30" as the draft name 503, for example, "2005 Z10Z30" which is the date when "Project A progress approval” is entered as the draft date. Enter “P00099”, an ID that can uniquely identify the user as the ID, and enter the projector HD “xxx” that can uniquely identify the project A to be confirmed as the project ID. For example, the “Register” button Press.
  • each input data input by the user is received by the second registration receiving means 113, and the second registration receiving means 113 receives each input data.
  • the information is stored in the workflow information storage means 109 provided in the DB server 103.
  • the input data entered in the workflow information table 501 shown in FIG. 5 is stored in the corresponding draft name 503, draft date 504, drafter ID 505, and project ID 506.
  • “AA-A AAA” which is a workflow ID that can uniquely identify a new registered workflow, is given by the second registration receiving means 113 and stored in the workflow ID 502.
  • the second registration accepting unit 113 stores task registration screen data for registering one or more approval tasks constituting the new approval workflow in the terminal 101.
  • the task registration screen data includes, for example, the input items shown in “Task information table B531” in FIG. 5, that is, workflow ID532, related workflow ID533, approval task ID534, approver ID535, processing order 536, etc.
  • workflow ID 532 is a value given to make the approval workflow uniquely identifiable, and “AA-AAAA” corresponds here.
  • the related workflow ID 533 is an ID that can uniquely identify the workflow to be approved. It is.
  • the approval task ID 534 is an ID that can uniquely identify the approval task. This approval task is a task for the approver uniquely identified by the approver ID 535 to approve the continuation of the project indicated by the related workflow ID 533.
  • the user selects “XX-XXX X” indicating project A as the related workflow ID 533, and three approval tasks “task ⁇ - ⁇ ” and “task ⁇ -2” ”task as the approval task ID 534.
  • Each input data is received by the second registration accepting means 113, and the second registration accepting means 113 stores each input data in the task information storage means 110 provided in the DB server 103.
  • a task information table B531 of the task information storage means 110 is provided, and the input content is stored in the associated workflow ID 533, approval task ID 534, approver ID 535, and processing order 536 corresponding thereto.
  • the acquisition unit 114 receives the approver ID5 35 in the task information table B531.
  • Search for workflow ID 532 including “P00002” (Fig. 7: S700 ⁇ S701), where the project A progress approval workflow with workflow ID “AA-AAAA” is applicable.
  • the related workflow ID 533 corresponding to the approval workflow whose workflow ID is “AA-AAAA” is acquired.
  • “XX-XXXX” is stored, and as a result, the acquisition means 114 reads the planned task A—l, from the task information table A511. It can be determined that design task A-2 and development task A-3 are tasks related to the approval decision.
  • the acquisition unit 114 determines the start scheduled date 515, the scheduled end date 515, the scheduled period 5 16, and the correction start from these three tasks. Scheduled date 517, Scheduled end date 518, Actual start date 519, Actual end date 52
  • the acquisition unit 114 that has acquired each data transmits the data to the screen generation unit 107, and the screen generation unit 107 generates approval screen data based on the latest data ( Figure 7: S703).
  • FIG. 8 shows an example when the approval screen data is displayed.
  • the current date and time area 802 indicated by a broken line
  • the scheduled start date and the planned end date for Project A the actual start date and the actual end date already entered by each person in charge are displayed. Is included (area 803 indicated by a dashed line).
  • the tasks that make up Project A Planning Task A—
  • the scheduled start date, scheduled end date, and progress rate are included. Furthermore, when the information is already entered by each person in charge, the actual start date and the actual end date are included (area 804 indicated by a broken line).
  • the approval screen data including the scheduled start date, scheduled end date, and progress is generated by the screen generation means 107, it is transmitted to the terminal 101 used by the approver A and displayed on the display means 105. Is done. In other words, the approver A is not updated on the date when the project A progress approval workflow ("AA-AA AA") was registered (the draft date 504 to 2005Z10Z14) and the latest progress (2005Z10Z16 state). Based on this, it is possible to determine whether or not Project A can be continued.
  • the approval screen 801 shows an example with "2005Z10Z16". Planning task A-1 has been completed as scheduled, and design task A-2 has been delayed by the scheduled power. The judgment is Is possible.
  • the approval result 537 indicates “approval” indicating the approval (FIG. 7: S704 ⁇ S705).
  • “2005/10/16” which is the approved bag is stored in the approval box 538.
  • “reject” button 806 is pressed, “reject” is stored in the approval result 537, and “2005/10/16” which is the rejected date is stored in the approval date 538 (see FIG. 7: S704 ⁇ S705).
  • development task A stored in the progress achievement task information table A511 of 3).
  • the specific numerical value is the state of the task information table A511, which is different from the time point of “2005Z10Z16”, that is, the scheduled correction start date 517 and the scheduled correction end date 518 by the schedule correction means 112. Is stored.
  • the acquisition means 114 from these three tasks, from the respective scheduled start date 515, scheduled end date 515, scheduled period 516, scheduled modification start date 517, scheduled modification end date 51 8, actual start Date 519, achievement end date 520, progress rate 521.
  • the acquisition unit 114 that has acquired each piece of information transmits the information to the screen generation unit 107, and the screen generation unit 107 generates approval screen data based on the latest data. .
  • the approval screen 901 includes the current date and time, the scheduled start date and the scheduled end date for Project A, and the actual start date and actual end date already entered by each person in charge, as described above.
  • the scheduled start date, scheduled end date, and progress rate are included. Furthermore, it has already been entered by each person in charge. In the case of a record, the result start date and the result end date are included.
  • development tasks for each task (planning task A-1, design task A-2, development task A-3) that constitutes project A, the scheduled start date, scheduled end date, and progress rate are included. Furthermore, it has already been entered by each person in charge. In the case of a record, the result start date and the result end date are included.
  • development tasks are included for development tasks.
  • A-3 includes the scheduled start date after correction (denoted 902).
  • design task A-2 and development task A-3 include the planned end dates (descriptions 903 and 904 indicated by *). These are the scheduled modification start date and scheduled modification end date, which are determined by the schedule modification means 112 to be unable to be completed by the scheduled termination date! /.
  • the approval screen data is created using the latest data as of the present time ("2005/10/29").
  • design task A-2 is behind schedule, so approver B can make a different decision than approver A approves.
  • approver B can make a different decision than approver A approves.
  • the approval workflow is approved by many approvers, it takes a long time to complete the approval workflow. Even in such a case, approval is possible based on the latest information that is not in the state at the time of registration.
  • the planned start date and the planned end date were corrected to show the progress rate.
  • other factors such as the cost of the project can be considered as material for determining the continuation of the project. Therefore, it may be configured to include these in the approval screen data.
  • the items shown in the task information table 1001 shown in FIG. 10 are added to the items in the task status table A511.
  • This item includes the planned cost 1002, which indicates the cost for each task at the time of approval of Project A, and the cost when the period from the planned start date to the planned end date (planned period 516) is extended. Cost 1003 and actual cost 1004 are included.
  • the planned cost 1002 is registered by the user when the workflow of Project A is registered.
  • the corrected cost 1003 is calculated based on the planned cost and the number of days extended by the budget correction means (not shown) provided in the application server 102 when the schedule correction means 112 is processed. To calculate.
  • the specific calculation procedure will be described by taking, for example, the case where the design task A-2 described above has been extended for 16 days and the scheduled modification end date 518 is modified to “2005Z11Z17”.
  • the budget correction means is the planned cost (16 million yen) ⁇ scheduled period (21 days) X (scheduled period (21 days) + extension days (16 days )),
  • the revised cost is calculated, that is, about 28.19 million yen.
  • the revised cost is stored in the revised cost 1003.
  • approval screen data is generated by the screen generation means 107 so as to be displayed in the areas 807 and 905 of the screens 801 and 901.
  • the actual cost 1004 is the ratio of the actual number of days (actual end date actual start date + 1) to the planned period by the above-mentioned budget correction means in the processing after the person in charge inputs the actual end date 520, for example. And based on the planned cost 1002. Specifically, for example, in the case of planning task A—1, the planned cost (8 million yen) ⁇ scheduled period 516 (10 days) X actual days (10 days) is calculated, and the actual cost is 8 million. Yen. The calculated actual cost is stored in the actual cost 1004, and the task for which the actual end date 520 is input is displayed by the screen generation means 107 in the areas 807 and 905 of the screens 801 and 901. . In addition, it is the revised cost that is enclosed in parentheses and is marked with “*”, and is marked with “*” and is displayed as actual cost.
  • the planned cost is corrected based on the planned period 516, progress rate 521, actual start date 519, actual end date 520, etc., and included in the approval screen data. Including approval can be determined.
  • the above-mentioned scheduled period 516, progress rate 521, actual start date 519, actual end date 520, etc. are updated as needed, so the cost based on the latest information can be confirmed, and accurate according to cost. Approval decision can be made.
  • the degree of importance may be further determined and displayed according to the cost change, and an approver may be added.
  • the application server 1102 includes an importance level determination unit 1103, an approval task determination unit 1104 in addition to the application server 102.
  • Approver adding means 11 05 is provided.
  • an importance level determination table 1201 and an approver table 1210 are stored.
  • the importance determination table 1201 includes the cost 1202 as a threshold, and the importance 1203 when the cost (planned cost data, corrected cost data, actual cost data) falls within the range of the threshold. It is stored in association.
  • the approver table 1210 stores an approver ID 1211 and an upper approver ID 1201 corresponding to the approver corresponding to the approver ID, for example, associated with the approver ID.
  • the importance determination means 1103 calculates, for example, when each task ID 513 is registered, when the planned cost 1002 or the actual cost 1004 is registered, and further, the corrected cost 1003 is calculated.
  • the importance level is determined at the determined timing. For example, refer to the planned cost data stored in the planned cost 1002 for the importance, determine which cost (threshold range) 1202 in the planned cost data importance level judgment table 1201 corresponds to the cost.
  • the importance 1203 corresponding to 1202 is the importance of the task.
  • the determined importance is stored in the importance 1005 of the task information table 1001. In this example, the power to be judged is the planned cost 1002.
  • Actual cost 1004 The priority order may be set in the order of the correction cost 1003 and the scheduled cost 1002.
  • the importance is determined based on the actual cost 1004, and when the actual cost 1004 is not entered, the importance is calculated based on the corrected cost 1003. . If the correction cost 1003 is not calculated, the importance may be determined based on the planned cost 1002. The importance determined in this way is stored in the importance 1005 of the task information table C 1001 in association with the task ID.
  • the approval task determination means 1104 sets the advance tasks that constitute the approval task to “all together”. It is determined whether or not it is a request for sending an approval task corresponding to the progress task 'whose progress is delayed and whose importance is equal to or higher than the previous importance level.
  • the "importantly set importance” is, for example, when "importance A” is stored in a storage means (not shown), and advancing tasks of importance A or higher are targeted. Become.
  • the importance level determined by the importance level determination unit 1103 may be set as a preset importance level. That is, when the importance is determined by the importance determination means 1103, the importance is higher than the previous importance.
  • the determination of "advanced progress tag" is, for example, whether or not the force corresponds to "when there is a large deviation in progress" during the processing by the schedule correction means 112 described above. In addition to this, it may be simply an advancement task in which the results sent from the scheduled date are entered.
  • the approval task determination means 1104 at least one of the advance tasks constituting the approval task is “importance more than the importance set in advance, and the advance is delayed.
  • the screen generation means 107 When it is determined that the approval task corresponding to the progressing task V corresponds, the screen generation means 107 generates approval screen data including the determined importance and transmits it to the terminal 101.
  • Design task A-2 on the approval screen corresponds to the above "Approval task corresponding to an advance task whose advancement is delayed and the advancement is delayed”. Then, the importance level display 1302 is displayed at the position corresponding to the design task A-2 on the approval screen 1301. ing.
  • the approval task determination means 1104 is an approval task corresponding to "an advancement task whose importance is greater than or equal to the importance set in advance and whose advancement is delayed".
  • the approver adding means 1105 may add a new approver.
  • the approver tracking means 1105 refers to the processing order 531 of the task information table B531. Then, the approver whose processing order is the last (in this case, the approver ID is P00004) is obtained, and further, by referring to the approver table 1201 in FIG. 12, the higher-order associated with the approver ID 1211 is obtained. Approver ID 1212 is acquired (in this case, approver ID is POOO 1 0). Subsequently, the approver adding means 1105 adds the acquired higher-level approver ID to the task information table B531.
  • the higher-level approver here refers to the person who corresponds to the supervisor of the approver, for example. However, the number of approvers may be simply increased, not limited to supervisors.
  • FIG. 14 shows an example of the task information table B1401 to which the higher approver ID is added.
  • Data power indicated by broken line 1402 Data related to the upper-level approver ID.
  • a new approver (approver that is higher than the approver) is added to the approver of the approval workflow for the advanced task with high importance and delay. Therefore, the continuation will be scrutinized and strict approval will be given as a whole.
  • a higher-level approver is added, for example, it is possible to determine at the same time, for example, a new management resource (human resource) for a delayed advancement task, so that the delay problem can be resolved early. Can lead.
  • the workflow system according to the present invention is useful as a workflow system in the management of a large-scale project.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

　最新情報に基づいたワークフロー上の承認処理を実現するワークフローシステムを提供する。本発明は、承認タスクを実施するための承認画面データの送信指示を受信した際に、送信指示を受信した際にタスク情報記憶手段に記憶されている１又は複数のタスクの開始予定日データと終了予定日データと進捗実績データとを取得し、当該進捗実績データを含む承認画面データを生成する承認画面生成手段を備えたワークフローシステムを提供する。

Description

明 細 書
ワークフローシステム、管理方法、プログラム及び記録媒体
技術分野
[0001] 本発明は、ワークフローシステム等に関するものである。
背景技術
[0002] 従来より、企業における業務の進拔には大勢の担当者が関わるのが通常である。こ のような進拔を管理する手段として、ワークフローシステムが導入されている。ワーク フローシステムの利用例として、例えばあるプロジェクトが複数の他の人物による承認 を必要とする場合、上記複数の他の人物にコンピュータネットワークを利用した回覧 などを用いて承認を伺 ヽ、承認されれば当該プロジェクトが許可される。
[0003] なお、特開 2002— 24499号公報に記載には、決裁書や議事録などの稟議書を、 ネットワークを介して効率的に回覧できる技術が開示されている。
[0004] また、特開 2002— 230249号公報には、決裁者が承認申請情報に容易にァクセ スできる技術が開示されている。
特許文献 1：特開 2002— 24499号公報
特許文献 2：特開 2002— 230249号公報
発明の開示
発明が解決しょうとする課題
[0005] ところで、大規模なプロジェクトが実施される場合、そのプロジェクトの開始から終了 までの期間が長期に及ぶことがある。このような場合には、例えば製品開発などでは 市場動向や進拔状況、予算 (財務状況）に応じて適宜プロジェクト継続の可否がチェ ックされる。ここで、承認を得られない場合には、例えばそのプロジェクトは中止される ことになる。
[0006] し力しながら、大規模なプロジェクトになればなるほど承認を得るべき責任者の人数 が増加するのが通常である。このような場合には、チェックのための"プロジェクト承認 ワークフロー"の登録から、最終承認者の承認までに時間を要する。このため、プロジ ェクト承認ワークフロー登録時の状況と承認時の状況とが大きく変化している可能性 が高ぐ責任者 (承認者）は古い情報に基づいてプロジェクト継続の可否判断を強い られること〖こなる。
[0007] また、例えば高ランクの承認者 (例えば社長）は、 日々多数のワークフローを処理す る必要に迫られる。このような場合に、重要度の低いワークフローと重要度の高いヮ ークフローが一様に判断され、即ち重要度の高 、ワークフローであっても安易に継続 が判断されるといった問題も生じる。
[0008] 本発明は上記従来の事情に基づ 、て提案されたものであって、最新情報に基づ ヽ たワークフロー上の承認処理を実現するワークフローシステム等を提供することを目 的とする。
課題を解決するための手段
[0009] 本発明は、上記目的を達成するために以下の手段を採用している。すなわち本発 明に係るワークフローシステムは、タスクを開始する予定日である開始予定日データ とタスクを終了する予定日である終了予定日データとに関連付けられたタスクを特定 可能な 1又は複数のタスク IDと、第一のワークフローを特定可能な第一のワークフロ 一 IDとを関連付けて記憶する第一のタスク情報記憶手段と、 1又は複数のタスク IDと 第一のワークフロー IDの入力を受け付けると共に第一のタスク情報記憶手段に記憶 する第一の登録受付手段と、タスクの進拔の実績を示す進拔実績データの更新を受 け付け、当該タスクのタスク IDと関連付けて第一のタスク情報記憶手段に記憶する進 拔受付手段と、第一のワークフローの継続を承認するための 1又は複数の承認タスク を特定可能な承認タスク IDと第二のワークフローを特定可能な第二のワークフロー I Dとを関連付けて記憶する第二のタスク情報記憶手段と、 1又は複数の承認タスク ID と上記第二のワークフロー IDの入力を受け付けると共に上記第二のタスク情報記憶 手段に記憶する第二の登録受付手段と、承認タスクを実施するための承認画面デー タの送信指示を受信した際に、送信指示を受信した際に第一のタスク情報記憶手段 に記憶されて 、る 1又は複数のタスクの開始予定日データと、終了予定日データと、 上記更新された進拔実績データとを取得する取得手段と、取得手段が取得した開始 予定日データと、終了予定日データと、進拔実績データとを含む承認画面データを 生成する承認画面生成手段とを備えて 、る。 [0010] このワークフローシステムにおいては、承認ワークフローの登録時点のタスク状態で はなぐ最新情報に基づいて承認が可能となるため、特に、承認ワークフローが多数 の承認者によって承認される場合などであっても最新の情報に基づいて承認処理が 可能である。
[0011] なお、第一のタスク情報記憶手段に記憶されるタスクは、プロジェクトの進拔を管理 する進拔ワークフローを構成する進拔タスクとすることができる。
[0012] また、進拔受付手段にて受け付けた進拔実績データに基づ!/、て、当該進拔実績デ ータに対応する上記進拔タスクの新たな終了予定日を修正終了予定日データとして 算出し、上記タスク IDと関連付けて記憶する日程修正手段を備え、承認画面生成手 段は、さらに修正終了予定日データを含む承認画面データを生成する構成がある。
[0013] この構成では、進拔状況に基づ 、て日程がどのように遅延して 、るかが一目瞭然と なり、正確な承認の判断が可能になる。
[0014] また、日程修正手段は、さらに修正終了日の出力の対象となった進拔タスクの終了 予定日に依存する進拔タスクが存在するか否かを判定するとともに、存在する場合に は、当該依存する進拔タスクについて新たな開始予定日と新たな終了予定日とを算 出し、修正開始予定日データ及び修正終了予定日データとして上記依存する進拔 タスクのタスク IDに関連付けて記憶し、承認画面生成手段は、依存するする進拔タス 、て修正開始予定日データ及び修正終了予定日データを含む承認画面デ ータを生成する構成がある。
[0015] この構成では、依存される進拔タスクの日程が変更された場合には当該タスクに依 存するタスクについても予定開始日 ·予定終了日が変更されるため、プロジェクト全 体としての遅延が明確に把握可能となり、いっそう正確な承認の判断が可能となる。
[0016] また、日程修正手段は、上記終了予定日と現在日付とを比較し、終了予定日から 所定日数前に該当する場合にのみ、上記修正終了予定日を算出する構成や、さら に上記進拔実績データがあら力じめ定められた閾値よりも小さい場合にのみ、上記 修正終了予定日を算出する構成がある。
[0017] この構成では、大きな進拔のずれが生じている場合にのみ、修正終了予定日を算 出するため、プロジェクト継続の可否に影響を与えない程度の遅延は承認画面に表 示されない。結果として、重大な遅延と軽微な遅延との識別を容易にし、承認者の負 担が軽減される。
[0018] さらに、第一のタスク情報記憶手段は、タスク IDと当該タスク IDに対応する作業の 実施時に必要とされる予定コストデータとを関連付けて記憶すると共に、進拔受付手 段にて更新を受け付けた進拔実績データと、上記予定コストデータとに基づいて、当 該進拔実績データに対応する上記タスクの新たな予定コストを修正コストデータとし て算出し、上記タスク IDと関連付けて記憶するコスト修正手段を備え、承認画面生成 手段は、修正コストデータを含む承認画面データを生成する構成がある。
[0019] この構成では、コストの増加を踏まえた正確な承認の判断が可能となる。
[0020] なお、上記ワークフローシステムは、コンピュータを用いて具体化することができる。
その場合、上述した各手段は、コンピュータ上でプログラムを動作させることにより具 体化される。また、記憶手段については HDD (Hard Disk Drive)や各種メモリにて具 体化される。
発明の効果
[0021] 本発明に係るワークフローシステムにおいては、承認ワークフローの登録時点のタ スク状態ではなぐ最新情報に基づいて承認が可能となるため、特に、承認ワークフ ローが多数の承認者によって承認される場合などであっても最新の情報に基づいて 承認処理が可能である。
[0022] また、進拔状況に基づいて日程がどのように遅延しているかが一目瞭然となり、正 確な承認の判断が可能になる。
[0023] さらに、依存される進拔タスクの日程が変更された場合には当該進拔タスクに依存 する進拔タスクについても予定開始日 ·予定終了日が変更されるため、プロジェクト 全体としての遅延が明確に把握可能となり、いっそう正確な承認の判断が可能となる
[0024] またさらに、最新のコストの増加の情報を踏まえた正確な承認の判断も可能となる。
[0025] また、重要度を表す表示を承認画面に付加することで、タスクが予定より遅滞して!/、 ること、及び当該タスクの規模が一見して明らかとなり、承認者はいつそう正確な判断 を下すことができる。 [0026] またさらに、重要度が高く且つ遅延が発生している進拔タスクに対しては、新たな承 認者 (承認者の上位に該当する承認者）が承認ワークフローの承認者に追加される ため、その継続が精査されることになり、全体として厳重な承認が行われることになる 。また、上位承認者が追加される場合には、例えば、遅延している進拔タスクに対し て新たな経営資源 (人材)を投入する等の判断まで同時に判定可能となり、遅延問題 を早期解決に導くことができる。
図面の簡単な説明
[0027] [図 1]図 1は、ワークフローシステムを構成する端末、アプリケーションサーバ、 DBサ ーバの概略機能ブロック図。
[図 2]図 2は、アプリケーションサーバの概略構成図。
[図 3]図 3は、ワークフローシステムのシステム構成例を示す図。
[図 4]図 4は、プロジェクトを構成する各ワークフローを示す図。
[図 5]図 5は、ワークフロー情報テーブル及びタスク情報テーブルの一例を示す図。
[図 6]図 6は、 日程修正処理の手順を示すフローチャート。
[図 7]図 7は、承認処理の手順を示すフローチャート。
[図 8]図 8は、承認画面の第一の例を示す図。
[図 9]図 9は、承認画面の第二の例を示す図。
[図 10]図 10は、タスク情報テーブルに追加される項目を示す図。
[図 11]図 11は、応用例 2に対応するワークフローシステムの概略機能ブロック図。
[図 12]図 12は、重要度判定テーブル及び承認者テーブルの一例を示す図。
[図 13]図 13は、承認画面の第三の例を示す図。
[図 14]図 14は、新たな承認者が追加されたタスク情報テーブルの一例を示す図。 発明を実施するための最良の形態
[0028] 以下、添付図面を参照して、本発明の実施の形態につき説明し、本発明の理解に 供する。尚、以下の実施の形態は、本発明を具体ィ匕した一例であって、本発明の技 術的範囲を限定する性格のものではない。また、本発明に係るワークフローシステム は、図 1に示すように端末 101、アプリケーションサーバ 102、データベースサーバ（D Bサーバ） 103がネットワークを介してそれぞれ通信可能に接続される力 例えばアブ リケーシヨンサーバ 102と DBサーバ 103とを同一コンピュータ上に設けてもよい。
[0029] 以下、本発明に係るワークフローシステムの処理にっ 、て説明する。
[0030] 図 1は、ワークフローシステム 100に対して各種データや命令を送受信する端末 10 1と、ワークフローシステム 100を構成するアプリケーションサーバ 102、 DBサーバ 1 03の概略機能ブロック図である力 各手段の処理等については後述する。
[0031] また、図 2は、アプリケーションサーバ 102の概略構成図であり、 CPU (Central Proc essing Unit) 201、 RAM (Random Access Memory) 202、 ROM (Read Only Memory ) 203、 HDD204及びネットワーク I/F (インターフェイス） 205力内部ノ ス 206を介 して接続されている。上記 CPU201は、例えば RAM202を作業領域として利用し、 ROM203や HDD204等に記憶されているプログラムを実行することで上記図 1に示 した各手段として動作する。上記ネットワーク IZF205は、ネットワークと接続されて おり、他の機器とデータの授受が可能となっている。また、端末 101、 DBサーバ 103 の構成も上記アプリケーションサーバ 102と同様であり、上記記憶されているプロダラ ムゃデータが異なることで、異なる処理を実行可能となって 、る。
[0032] 図 3は、ワークフローシステム 100のシステム構成例であり、複数の端末 101、アプリ ケーシヨンサーバ 102、及び DBサーバ 103がインターネットやイントラネット等のネッ トワーク 207を介して通信可能に接続されて 、る。
[0033] 続いて、ワークフローシステム 100における処理について説明する。
[0034] なお、理解に供するため、上記ワークフローシステム 100にはすでに実施が承認さ れて 、るプロジェクト Aが登録されて 、るものとして説明する。
[0035] 図 4に示すように、上記プロジェクト A401は、企画（タスク A— 1)、設計（タスク A— 2)、開発 (タスク A— 3)より構成されるプロジェクト進拔ワークフロー 402を基本として 構成されており、企画が完了すると設計が実施可能となり、設計が完了すると開発が 実施可能となる構成である。つまり、上記タスク A—l、タスク A— 2、タスク A— 3は、 プロジェクトの進拔を管理する進拔ワークフローを構成する進拔タスクである。
[0036] また、上記企画タスク A— 1、設計タスク A— 2、開発タスク A— 3は、タスク進拔ヮー クフロー 403、 404、 405としてそれぞれワークフローシステム 100に登録されている 。当該タスク進拔ワークフロー 403〜405に担当者が進拔実績データを新たに入力 し、さらに随時更新することにより、各タスク A—l、 A— 2、 A— 3の進拔状況を把握可 能となっている。なお、上記進拔実績データに対する入力は、本願における進拔実 績データの更新に含まれるものとする。
[0037] また、各タスク進拔ワークフロー 403〜405の完了が確認されると、上記プロジェクト 進拔ワークフロー 402に反映され、継続する他のタスクが実施可能となる力 詳細は 後述する。
[0038] さらに、上記プロジェクト A401には、プロジェクト承認ワークフロー 406が登録され ている。当該プロジェクト承認ワークフロー 406は、承認 A (承認タスク B— 1)、承認 B (承認タスク B— 2)、承認 C (承認タスク B— 3)よりなる。プロジェクト承認ワークフロー 406は、上記プロジェクト A401が終了するまでにたとえば複数回、定期的に登録及 び実施され、すなわちプロジェクト A401を見直すためのワークフローである。また、 上記承認タスク B— 1〜承認タスク B— 3がすべて承認されることで、プロジェクト A40 1の継続が許可される。当該承認タスクは、承認を必要とするタスクという意味で、上 記進拔タスクと異なる。
[0039] (進拔管理ワークフロー登録処理）
次に、上記プロジェクト A401に関連するワークフローが登録されるまでの処理を説 明する。
[0040] ユーザが端末 101を利用して図 1に示すアプリケーションサーバ 102にアクセスす る。当該アクセスは、例えばユーザがマウスやキーボード等の入力手段 104を利用し て端末 101上でブラウザ等の所定のソフトウェアを起動し、ディスプレイ等の表示手 段 105に表示された当該ソフトウェアのアドレス欄にアプリケーションサーバ 102の U RL (Uniform Resource Locator)を入力することにより行われる。
[0041] 端末 101によるアクセスは、アプリケーションサーバ 102の送受信手段 106を介して 例えば画面生成手段 107にて検知され、当該画面生成手段 107は、端末 101に対 してワークフローシステム 100が提供する処理のメニュー（図示せず）を送信する。送 信されたメニューは端末 101にて受信され、表示手段 105に表示される。
[0042] 表示手段 105に表示された上記メニューには、例えば新たなワークフローを登録す るための項目が含まれており、端末 101のユーザは当該項目を入力手段 104より選 択することで、その旨を示す信号が送受信手段 106にて受信される。当該送受信手 段 106は、上記項目が選択された旨を示す信号を判定し、当該項目の処理に対応 する第一の登録受付手段 108に当該信号を送信する。
[0043] 例えば、プロジェクト進拔ワークフロー 402をユーザが登録する場合、上記メニュー を構成する複数の項目のうち、 "プロジェクト進拔ワークフロー登録"を選択する。当 該"プロジェクト進拔ワークフロー登録"が選択された旨を示す信号は、上記第一の 登録受付手段 108にて受信され、プロジェクト進拔ワークフロー登録のための入力項 目を含むワークフロー登録画面データが端末 101に返信される。返信されたワークフ ロー登録画面データは、端末 101の表示手段 105にて表示される。
[0044] 上記ワークフロー登録画面データには、例えば図 5の"ワークフロー情報テーブル 5 01"に示される入力項目、すなわち、起案名 503、起案日 504、起案者 ID505、プロ ジェタト ID506等が含まれる。
[0045] 表示された上記ワークフロー登録画面に対して、ユーザは、上記起案名 503として 、例えば"プロジェクト A"を、起案日として入力している日付である例えば" 2005Z9 Z10"を、起案者 IDとして入力ユーザを一意に識別可能な IDである" Ρ0000Γを、プ ロジェタト IDとして、既にプロジェクトの実施を承認されているプロジェクト Aを一意に 識別可能なプロジェクト ID"xxx"を入力し、例えば"登録"ボタン（図示せず)を押下 する。
[0046] 上記"登録"ボタンが押下されると、ユーザに入力された各入力データが上記第一 の登録受付手段 108にて受信され、当該第一の登録受付手段 108は、各入力デー タを DBサーバ 103に設けられたワークフロー情報記憶手段 109に記憶する。具体的 には、例えばワークフロー情報記憶手段 109には、図 5に示したワークフロー情報テ 一ブル 501が設けられており、入力された入力データが対応する起案名 503、起案 日 504、起案者 ID505、プロジェクト ID506に格納される。この際、登録された新たな ワークフローを一意に特定可能なワークフロー ID502である" XX-XXXX"が上記第一 の登録受付手段 108により与えられ、ワークフロー ID502に記憶される。
[0047] 新たなワークフロー、すなわちプロジェクト進拔ワークフロー 402が登録されると、上 記第一の登録受付手段 108は、当該新たなワークフローを構成する 1又は複数のタ スクを登録するためのタスク登録画面データを端末 101に送信する。当該タスク登録 画面データには、例えば図 5の"タスクテーブル A511"に示される入力項目、すなわ ち、タスク ID513、開始予定日 514、終了予定日 515、依存先 522等が含まれる。
[0048] 表示された上記タスク登録画面に対して、ユーザは、タスク ID513として例えば"企 画タスク A— 1"、 "設計タスク A— 2"、 "開発タスク A— 3"を入力し、当該各タスクの開 始予定日としてそれぞれ" 2005ZlOZ01，，、 "2005/10/11", "2005/11/0 1"を、当該タスクの終了予定日としてそれぞれ" 2005Ζ10Ζ10"、 "2005/10/3 1"、 "2005Z11Z30"を、 "設計タスク Α— 2"の依存先として"企画タスク A—1"を、 "開発タスク Α— 3"の依存先として"設計タスク Α— 2"を入力し例えば"登録"ボタン を押下する。なお依存先とは、当該タスクを開始する際に、完了していることが前提と されるタスクである。
[0049] 上記"登録"ボタンが押下されると、ユーザに入力された各入力データが上記第一 の登録受付手段 108にて受信され、当該第一の登録受付手段 108は上記各入力デ ータを DBサーバ 103に設けられたタスク情報記憶手段 110に記憶する。具体的には 、例えばタスク情報記憶手段 110には、図 5に示したタスク情報テーブル A511が設 けられており、入力された入力データが対応するタスク ID513、開始予定日 514、終 了予定日 515、依存先 522に格納される。この際、登録された新たなタスク IDに関連 するワークフロー ID512として、上記プロジェクト Aのワークフロー IDがワークフロー ID 512に記憶される。また、第一の登録受付手段 108は、開始予定日 514と終了予定 日 515とよりタスクの開始力も終了までの期間である予定期間を算出し、予定期間 51 6に格納する。
[0050] 上記処理により、図 4に示す、企画タスク A— 1、設計タスク A— 2、開発タスク A— 3 により構成されるプロジェクト進拔ワークフロー 402と、上記企画タスク A— 1に対応す るタスク進拔ワークフロー 403と、上記設計タスク A— 2に対応するタスク進拔ワークフ ロー 404と、開発タスク A— 3に対応するタスク進拔ワークフロー 405とがワークフロー 情報記憶手段 109及びタスク情報記憶手段 110に登録される。
[0051] (進拔ワークフローの更新）
続いて、プロジェクト進拔ワークフロー 402と、各タスク進拔ワークフロー 403〜405 の更新処理にっ 、て説明する。
[0052] まず、企画タスク A— 1の進拔管理を担当する担当者は、端末 101よりアプリケーシ ヨンサーバ 102にアクセスする。そして、メニューより例えば"進拔実績データ入力"を 選択するとともに、企画タスク A— 1に対応するタスク進拔ワークフロー 403を選択す る。当該"進拔実績データ入力"が選択された旨を示す信号は、送受信手段 106を 介して進拔受付手段 111にて受信される。そして進拔受付手段 111は、タスク情報テ 一ブル A511より、上記企画タスク A—1の開始予定日 514、終了予定日 515、実績 開始日 519、実績終了日 520、進拔率 521を取得し、画面生成手段 107に送信する 。画面生成手段 107は、上記取得された開始予定日 514、終了予定日 515、実績開 始日 519、実績終了日 520、進拔率 521に基づいて、進拔実績データを入力するた めの進拔実績入力画面データを作成し、端末 101に送信する。なお、ここでいぅ進拔 実績データとは、実績開始日 519、実績終了日 520、進拔率 521を指す。
[0053] 送信された進拔実績入力画面データは、端末 101の表示手段 105に表示される。
表示された進拔実績入力画面に対して上記担当者が、その日の進拔度合いを考慮 して、予定期間に対する作業の進拔率を入力する。入力された進拔率は、進拔率受 付手段 111を介してタスク情報記憶手段 110の進拔率 521に上書きされ、すなわち 更新される。なお、作業を開始した日の入力であれば、実際に作業を開始した日を 示す実績開始日に日付を入力する。また、企画タスク A— 1の作業が終了した日の入 力であれば、実際に作業が終了した日を示す実績終了日に日付を入力するとともに 、進拔率として 100%を入力する。当該入力に基づいて、タスク情報テーブル A511 の実績開始日 519、実績終了日 520、進拔率 521が更新され、すなわち入力が反映 される。
[0054] 上記処理により、各タスクの日々の作業実績が、タスク進拔ワークフロー 403〜405 に反映される。また、例えば企画タスク A—1の実績終了日 520が入力されると、当該 タスクを依存先とする設計タスク A— 2 (タスク進拔ワークフロー 404)の作業を進める ことが可能になり、ワークフローシステム 100上においては、当該設計タスク A— 2の 進拔率の入力 ·更新が可能になる。
[0055] (日程修正処理） 続、て、上記進拔実績データの入力に基づ 、て、新たな開始予定日である修正開 始日および新たな終了予定日である修正終了日を算出する処理につ!、て説明する
[0056] 上記アプリケーションサーバ 102が備える日程修正手段 112は、例えば毎日定めら れた時間に、 日程修正処理を行う。当該日程修正処理は以下のように行われる。
[0057] すなわち、まず、アプリケーションサーバ 102を構成する日程修正手段 112は、対 象となるタスク (ここでは企画タスク A—l、設計タスク A— 2、開発タスク A— 3)毎に、 開始予定日 514、終了予定日 515、修正終了予定日 518、予定期間 516、実績終 了日 520を取得する（図 6： S601)。
[0058] 次に、まだ完了していないタスク、すなわち実績終了日 520が入力されていないタ スクについて、現在の日付が終了予定日 515よりも所定日数前であるか否かを判定 する（図 6： S602)。例えば、タスク情報テーブル A511に記憶されて 、る内容で判定 した場合、企画タスク A—1はすでに実績終了日 520に日付が入力され、進拔率 51 2が 100%となっているため、上記判定は行われることなく日程修正処理は終了する (図 6 : S602No→終了）。また、設計タスク A— 2は実績終了日 520に日付が入力さ れていないためタスクは終了しておらず、終了予定日 515 (2005ZlOZ31)と現在 の日付とを比較し、現在の日付が終了予定日 515の所定日数前であるか否かを判 定する（図 6 : S602)。ただし、後述する修正終了予定日 518に日付が入力されてい る場合には、上記終了予定日 515に変えて修正終了予定日 518と現在の日時とを 比較する。
[0059] ところで、上記所定日数は、例えば (予定期間 516 X 0. 1)として算出される。これ は、予定終了日直前のものについてのみ、開始予定日 514及び終了予定日 515か ら修正開始予定日 517及び修正終了予定日 518を算出するためである。例えば、設 計タスク A— 2の日程修正処理が 2005Z10Z29に行われたと仮定すると、予定期 間 = 21となり、所定日数は 2. 1日（切り上げの場合には 3日）となる。所定日数" 3日 " と、現在日付" 2005Z10Z29"と、終了予定日" 2005Z10Z31"とを比較すること で、処理 S602における判定は" Yes"となる。
[0060] 次に、現在の日付が終了予定日 515の所定日数前であると判定された場合、対象 タスク（ここでは設計タスク A— 2)の進拔率 521 (ここでは 25%)を取得する（図 5： S6 03)。そして、当該進拔率が所定の値 (ここでは 50%)以下である力否かを判定する（ 図 6 : S604)。ここでは、終了予定日が近いにもかかわらず、進拔率が低いタスクの みを選別しているのである。ここで、進拔率が所定の値以下である場合、終了予定日 が近いにもかかわらず進拔率が低いことを意味し、現状の終了予定日（または修正 終了予定日）では作業の終了が困難であると判定される。したがって、この場合には 、進拔受付手段 111にて受け付けた進拔実績のうち進拔率 521に基づいて、日程修 正手段 112は、当該設計タスク A— 2の新たな終了予定日を算出し、修正終了予定 日として修正終了予定日 518に記憶する。
[0061] なお、上記修正終了予定日は、例えば以下のように算出される。すなわち、まず、 設計タスク A— 2の予定期間 516"21日"を取得し、これに 100%から現在の進拔率 5 21"250/0"を弓 | ヽた値" 750/0"を乗ずるのである。これ【こより、 21 X 0. 75 = 15. 75 ( 切り上げで 16日）が延長日数となる。実績開始日 519"2005Z10Z12"から、延長 日数" 16日 "と予定期間 516"21日 "とをカ卩えた 37日後（当日を含む）の" 2005/11 Z17"が修正終了予定日として算出される（図 6 : S605)。当該算出された値は、設 計タスク A— 2に対応する修正終了予定日 518に記憶される。
[0062] 上記日程修正手段 112による処理により、実際の進拔実績に応じた新たな予定日 が設定されるに至る。
[0063] 続いて、上記日程修正手段 112は、当該設計タスク A— 2を依存先とし、すなわち 設計タスク A— 2の終了予定日に依存する他のタスクが存在するか否かを判定する（ 図 6 : S606)。ここでは、タスク情報テーブル A511の開発タスク A— 3の依存先 522 に"設計タスク A— 2"が記憶されているため、設計タスク A— 2の終了予定日に依存 する開発タスク A— 3が存在する。存在する場合には、当該依存するタスクについて、 開始予定日 "2005Z11Z01" (修正開始予定日 517がすでに入力されている場合 には修正開始予定日）に、上記延長日数" 16日 "を加算した日である" 2005Z11Z 16"が修正開始予定日として算出される。また、当該修正開始予定日に予定期間 51 6"30日 "を加算した日が修正終了予定日 518として算出される。算出された値は、タ スク情報テーブル A511の開発タスク A— 3に対応する修正開始予定日 517及び修 正終了予定日 518に記憶される。
[0064] 以上の処理により、終了予定日が変更されたタスク (設計タスク A— 2)に対応するタ スク（開発タスク A— 3)の開始予定日および終了予定日も修正開始予定日及び修正 終了予定日として修正される。上記処理例に従って修正した後のテーブル力 図 5に 示すタスク情報テーブル A511である。
[0065] なお、上記処理により進拔状況に基づいて日程がどのように遅延しているかが一目 瞭然となり、後述する承認時には正確な承認の判断が可能になる。
[0066] さらに、依存されるタスクの日程が変更された場合には当該タスクに依存するタスク についても予定開始日 ·予定終了日が変更されるため、プロジェクト全体としての遅 延が明確に把握可能となり、いっそう正確な承認の判断が可能となる。
[0067] また、大きな進拔のずれが生じている場合にのみ、修正終了予定日を算出するた め、プロジェクト継続の可否に影響を与えない程度の遅延は承認画面に表示されな い。結果として、重大な遅延と軽微な遅延との識別を容易にし、承認者の負担が軽 減される。
[0068] (承認ワークフロー登録処理）
次に、上記プロジェクト A401に関連し、プロジェクト A401の継続を承認するための ワークフローが登録されるまでの処理を説明する。
[0069] ユーザが端末 101を利用してアプリケーションサーバ 102にアクセスし、メニュー を受信する点は"進拔管理ワークフロー登録処理"と同様である。
[0070] 表示手段 105に表示された上記メニューには、承認のための新たなワークフローを 登録するための項目が含まれている。承認のためのワークフローを登録しょうとする ユーザは当該項目を入力手段 104により選択することで、その旨を示す信号が送受 信手段 106にて受信される。当該送受信手段 106は、上記項目が選択された旨を示 す信号を判定し、当該項目の処理に対応する第二の登録受付手段 113に上記項目 が選択された旨を示す信号を送信する。
[0071] 例えば、プロジェクト A承認のためのワークフローをユーザが登録する場合、上記メ ニューを構成する複数の項目のうち、 "承認ワークフロー登録"を選択する。当該"承 認ワークフロー登録"が選択された旨は、上記第二の登録受付手段 113にて受信さ れ、承認ワークフロー登録のための入力項目を含む承認ワークフロー登録画面デー タが端末 101に返信される。返信されたワークフロー登録画面データは、端末 101の 表示手段 105にて表示される。
[0072] 表示された承認ワークフロー登録画面には、例えば図 5の"ワークフロー情報テー ブル 501"に示される入力項目、すなわち、起案名 503、起案日 504、起案者 ID505 、プロジェクト ID506等が含まれる。
[0073] 上記承認ワークフロー登録画面に対して、ユーザは、上記起案名 503として、例え ば"プロジェクト A経過承認"を、起案日として入力している日付である例えば" 2005 Z10Z30"を、起案者 IDとして入力ユーザを一意に識別可能な IDである" P00099" を、プロジェクト IDとして、継続を確認すべきプロジェクト Aを一意に識別可能なプロジ エタ HD"xxx"を入力し、例えば"登録"ボタンを押下する。
[0074] 上記"登録"ボタンが押下されると、ユーザにより入力された各入力データが上記第 二の登録受付手段 113にて受信され、当該第二の登録受付手段 113は各入力デー タを DBサーバ 103に設けられたワークフロー情報記憶手段 109に記憶する。具体的 には、図 5に示したワークフロー情報テーブル 501の、入力された入力データが対応 する起案名 503、起案日 504、起案者 ID505、プロジェクト ID506に格納される。この 際、登録された新たなワークフローを一意に識別可能なワークフロー IDである" AA-A AAA"が上記第二の登録受付手段 113により与えられ、ワークフロー ID502に記憶さ れる。
[0075] 新たなワークフローが登録されると、上記第二の登録受付手段 113は、当該新たな 承認ワークフローを構成する 1又は複数の承認タスクを登録するためのタスク登録画 面データを端末 101に送信する。当該タスク登録画面データには、例えば図 5の"タ スク情報テーブル B531"に示される入力項目、すなわち、ワークフロー ID532、関連 ワークフロー ID533、承認タスク ID534、承認者 ID535、処理順序 536等が含まれる
[0076] ここで、ワークフロー ID532は、承認ワークフローを一意に識別可能にするために与 えられた値であり、ここでは" AA-AAAA"が該当する。
[0077] また、関連ワークフロー ID533は、承認すべきワークフローを一意に識別可能な ID である。
[0078] 承認タスク ID534は、承認タスクを一意に特定可能な IDである。当該承認タスクは、 承認者 ID535により一意に特定される承認者が、関連ワークフロー ID533にて示され るプロジェクトの継続を承認するためのタスクである。
[0079] ここでは、ユーザは、関連ワークフロー ID533としてプロジェクト Aを示す" XX- XXX X"を選択し、承認タスク ID534として 3つの承認タスグ'タスク Β-Γ、 "タスク Β-2""タス ク Β-3"を入力し、それぞれの承認者 IDを" Ρ00002"、 "Ρ00003"、 "Ρ00004"とする。ま た、当該承認タスクの処理順序を、 "タスク Β-Γ、 "タスク Β-2""タスク B-3"の順として 入力する。入力後に、例えばユーザ力 '登録"ボタンを押下することで、入力された各 入力データが上記第二の登録受付手段 113にて受信され、当該第二の登録受付手 段 113は、各入力データを DBサーバ 103に設けられたタスク情報記憶手段 110に記 憶する。具体的には、例えばタスク情報記憶手段 110のタスク情報テーブル B531が 設けられており、入力された内容が対応する関連ワークフロー ID533、承認タスク ID5 34、承認者 ID535、処理順序 536に格納される。
[0080] 上記処理により、図 4に示す、プロジェクト承認ワークフロー 406が登録される。
[0081] (承認処理）
続、て、承認者がプロジェクト Aの継続を承認する処理にっ 、て説明する。
[0082] まず、承認者 IDが" P00002"である承認者 A力 端末 101よりアプリケーションサー ノ 102にアクセスし、取得したメニューから"承認タスグ'を選択したものと仮定する。 なお、メニューを取得するまでの処理は上述したとおりである。
[0083] 承認者 Aが"承認タスグ'を選択した旨の信号が送受信手段 106を介して取得手段 114にて受信されると、取得手段 114は、タスク情報テーブル B531内の承認者 ID5 35力ら" P00002"を含むワークフロー ID532を検索する（図 7： S700→S701)。ここで は、ワークフロー IDが" AA-AAAA"であるプロジェクト A経過承認ワークフローが該当 する。
[0084] 続いて、ワークフロー IDが" AA-AAAA"の承認ワークフローに対応する関連ワーク フロー ID533を取得する。当該関連ワークフロー IDには、 "XX- XXXX"が格納されて おり、これにより、取得手段 114は、タスク情報テーブル A511より企画タスク A—l、 設計タスク A— 2、開発タスク A— 3が承認の判断に関連するタスクであると判定でき る。
[0085] 上記各タスクが承認の判断に関連するタスクであると判定すると、取得手段 114は 、これら 3つのタスクから、それぞれの開始予定日 515、終了予定日 515、予定期間 5 16、修正開始予定日 517、修正終了予定日 518、実績開始日 519、実績終了日 52
0、進拔率 521を取得する（図 7 : S702)。なお、上記各タスクに関する修正開始予定 日 517、修正終了予定日 518、実績開始日 519、実績終了日 520、進拔率 521は、 随時担当者によって更新されているため、上記取得手段 114が取得したデータは、 承認ワークフロー" AA-AAAA"の起案日の状態ではなぐ適宜更新された最新のデ ータである。
[0086] 続いて、上記各データを取得した取得手段 114は、当該各データを画面生成手段 107に送信し、当該画面生成手段 107は、上記最新のデータに基づいて承認画面 データを生成する（図 7： S703)。
[0087] なお、承認画面データの表示時の一例を図 8に示す。承認画面 801には、現在日 時 (破線で示された領域 802)や、プロジェクト Aについての、開始予定日、終了予定 日、各担当者によって既に入力されている実績開始日、実績終了日が含まれている (破線で示された領域 803)。また、プロジェクト Aを構成する各タスク (企画タスク A—
1、設計タスク A— 2、開発タスク A— 3)について、開始予定日、終了予定日、進拔率 が含まれている。またさらに、各担当者によって既に入力されている場合には実績開 始日、実績終了日が含まれる (破線で示された領域 804)。
[0088] 上記開始予定日、終了予定日、進拔実績を含む承認画面データが画面生成手段 107により生成されると、上記承認者 Aが利用する端末 101に送信され、表示手段 1 05に表示される。つまり、承認者 Aは、プロジェクト A経過承認ワークフロー（"AA-AA AA")が登録された日（起案日 504より 2005Z10Z14)の状態ではなぐ更新された 最新の進拔実績（2005Z10Z16の状態）に基づいて、プロジェクト Aの継続の可否 につ 、て判断することが可能となる。
[0089] なお、承認画面 801に示したものは、 "2005Z10Z16"付けの例であり、企画タス ク A— 1が予定通り完了し、設計タスク A— 2も予定日力 遅れて 、な 、と 、う判断が 可能である。
[0090] 上記承認画面 801の表示に対して、承認者 Aが例えば"承認"ボタン 805を押下す ると、その旨を示す信号が承認受付手段 115により受信され、当該承認受付手段 11 5力 タスク情報テーブル B531の承認結果 537に承認された旨を示す"承認"を記 '慮させる（図 7 : S704→S705)。また、承認曰 538には承認された曰である" 2005/ 10/16"を記憶させる。なお、 "却下"ボタン 806が押下された場合には、承認結果 5 37に"却下"を記憶させ、承認日 538には却下された日である" 2005/10/16"を 記憶させる（図 7： S704→S705)。
[0091] 続、て、承認者 Bがプロジェクト Aの継続を承認する場合にっ 、て説明する。承認 者 IDが" P00003"である承認者 B力 端末 101よりアプリケーションサーバ 102にァク セスし、取得したメニューから"承認タスグ'を選択したものと仮定する。なお、当該処 理は" 2005Z10Z29"に実行したものする。
[0092] この場合には、 "2005Z10Z29"時点の各タスク（企画タスク A—l、設計タスク A
- 2、開発タスク A— 3)の進拔実績力タスク情報テーブル A511に記憶されて 、る。 なお、具体的な数値は上記で説明したように、タスク情報テーブル A511の状態であ り、 "2005Z10Z16"時点とは異なり、すなわち、日程修正手段 112により修正開始 予定日 517及び修正終了予定日 518が格納されている状態である。
[0093] このような状態で取得手段 114は、これら 3つのタスクから、それぞれの開始予定日 515、終了予定日 515、予定期間 516、修正開始予定日 517、修正終了予定日 51 8、実績開始日 519、実績終了日 520、進拔率 521を取得する。
[0094] 続いて、上記各情報を取得した取得手段 114は、当該各情報を画面生成手段 107 に送信し、当該画面生成手段 107は、上記最新のデータに基づいて承認画面デー タを生成する。
[0095] 承認画面の一例を図 9に示す。承認画面 901には、上記同様、現在日時や、プロ ジェタト Aについての、開始予定日、終了予定日、各担当者によって既に入力されて いる実績開始日、実績終了日が含まれている。また、プロジェクト Aを構成する各タス ク（企画タスク A— 1、設計タスク A— 2、開発タスク A— 3)について、開始予定日、終 了予定日、進拔率が含まれている。またさらに、各担当者によって既に入力されてい る場合には実績開始日、実績終了日が含まれる。さらにこれらに加えて、開発タスク
A— 3には、修正後開始予定日（※で示された記載 902)が含まれている。また、設計 タスク A— 2及び開発タスク A— 3には、修正後終了予定日（※で示された記載 903、 904)が含まれている。これらは、日程修正手段 112によって終了予定日までに終了 できな!/、と判断され、修正された修正開始予定日及び修正終了予定日である。
[0096] つまり、上記承認者 Aが継続を承認した際の承認画面とは異なり、現在 ("2005/ 10/29")時点の最新のデータを用いて承認画面データが作成されている。この承 認画面では、設計タスク A— 2が予定より遅滞していることが一見して明らかであるの で、承認者 Bは承認者 Aが承認した際とは違った判断を下すことができる。特に、承 認ワークフローが多数の承認者によって承認される場合などには、承認ワークフロー が完了するまでに長期間を要する。このような場合でも、登録時点の状態ではなぐ 最新情報に基づいて承認が可能となるのである。
[0097] 以上のように、日々更新される進拔実績に基づ!/、て、承認時の承認画面データを 作成することで、最新情報に基づ 、たワークフロー上の承認処理を実現することがで きる。
(応用例 1)
なお、上記例では、進拔の遅延をプロジェクト継続の判断材料とするために、開始 予定日、終了予定日を修正し、進拔率を示していた。プロジェクト継続の判断材料と しては、上記以外に例えば当該プロジェクトにかかるコストなどが考えられる。よってこ れらを上記承認画面データに含むように構成してもよ 、。
[0098] 具体的には、例えばタスク状態テーブル A511の項目に、図 10に示すタスク情報 テーブル 1001に示す項目を追加する。当該項目には、プロジェクト Aの承認時のタ スク毎のコストを示す予定コスト 1002と、開始予定日から終了予定日までの期間（予 定期間 516)が延長された際のコストである修正後コスト 1003と、実績コスト 1004と が含まれる。
[0099] 予定コスト 1002は、プロジェクト Aのワークフロー登録時にユーザが登録するもので ある。修正後コスト 1003は、日程修正手段 112の処理時に、例えばアプリケーション サーバ 102に備えられた図示しない予算修正手段が予定コストと延長日数に基づい て算出する。具体的な算出手順を、例えば上述した設計タスク A— 2にて 16日の延 長がされ、修正終了予定日 518が" 2005Z11Z17"と修正された場合を例にして説 明する。この場合、 日程修正手段 112による日付の修正と同じタイミングで、予算修 正手段が予定コスト（1600万円） ÷予定期間（21日） X (予定期間（21日） +延長日 数（16日））として修正後コストを算出し、すなわち約 2819万円となる。当該修正後コ ストは、修正後コスト 1003に格納される。そして、必要に応じて画面生成手段 107に より、画面 801や 901の領域 807や領域 905に表示されるように承認画面データが 作成される。
[0100] また実績コスト 1004は、例えば担当者が実績終了日 520を入力した後の処理にお いて、上記予算修正手段が、予定期間に対する実績日数 (実績終了日 実績開始 日 + 1)の割合と、予定コスト 1002に基づいて算出する。具体的には、例えば企画タ スク A— 1を例にとると、予定コスト（800万円） ÷予定期間 516 (10日） X実績日数（1 0日）として算出され、実績コストは 800万円となる。当該算出された実績コストは、実 績コスト 1004に格納され、実績終了日 520が入力されているタスクについては、画 面生成手段 107により、画面 801や 901の領域 807や領域 905に表示される。なお 、括弧にて括られており且つ"※"が付されているのが修正後コストであり、 "※"が付 されて 、な 、ものが実績コストとして表示されて 、る。
[0101] このように、予定期間 516、進拔率 521、実績開始日 519、実績終了日 520等に基 づいて予定コストを修正し、承認画面データに含めることで、日程だけでなく予算を 含めて承認の判定が可能になる。当然、上記予定期間 516、進拔率 521、実績開始 日 519、実績終了日 520等は随時更新されているため、最新の情報に基づいたコス トを確認することができ、コストに応じた正確な承認判断が可能となる。
(応用例 2)
上記例では、進拔の遅延をプロジェクト継続の判断材料とするために、開始予定日 、終了予定日を修正し、進拔率を示していた。またこれにカ卩えて、応用例 1では、プロ ジェタトに関するコストまでも自動的に修正されて承認画面データに表示されていた 。ここで、プロジェクトの規模が大きくなるほど、そのプロジェクトの重要度が高くなるの が通常である。プロジェクトのコストが増加すると、当該プロジェクトの企業経営に与え る影響が大きくなるためである。
[0102] そこで、プロジェクトのコストが動的に修正される本願のシステムでは、さらにそのコ ストの変更に応じて重要度が判定されて表示され、さらに承認者を追加する構成とし てもよい。
[0103] 具体的には図 11のワークフローシステム 1100を構成するアプリケーションサーバ 1 102に示すように、当該アプリケーションサーバ 1102には、アプリケーションサーバ 1 02に加えて重要度判定手段 1103、承認タスク判定手段 1104、承認者追加手段 11 05が備えられる。
[0104] また、タスク情報記憶手段 110には、上記応用例 1に示すように、図 10に示すタス ク情報テーブル 1001に示す項目が追加されている。ただしここでは、さらに重要度 1
005が追加されており、詳細については後述する。
[0105] また、例えばワークフロー情報記憶手段 109、タスク情報記憶手段 110には、図 12 に示すように、重要度判定テーブル 1201及び承認者テーブル 1210が格納されて いる。
[0106] また、上記重要度判定テーブル 1201には、閾値となるコスト 1202と、コスト（予定コ ストデータ、修正コストデータ、実績コストデータ）が当該閾値の範囲に該当する場合 の重要度 1203が関連付けて記憶されて 、る。
[0107] さらに、上記承認者テーブル 1210には、承認者 ID1211と、当該承認者 IDに該当 する承認者の例えば上司に該当する上位承認者 ID1201とが関連付けて記憶され ている。
[0108] さて、このような構成において、重要度判定手段 1103は、例えば各タスク ID513が 登録された場合や、予定コスト 1002や実績コスト 1004が登録された場合、さらには 、修正コスト 1003が算出されたタイミングで、重要度の判定を行う。当該重要度は、 例えば予定コスト 1002に格納される予定コストデータを参照し、当該予定コストデー タカ 重要度判定テーブル 1201のどのコスト（閾値の範囲） 1202に該当するかを判 定して、そのコスト 1202に対応する重要度 1203が、そのタスクの重要度とされる。判 定された重要度は、上記タスク情報テーブル 1001の重要度 1005に格納される。な お、ここでは、判定の対象とされるコストを予定コスト 1002とした力 実績コスト 1004 、修正コスト 1003、予定コスト 1002の順序で優先順位を設けてもよい。すなわち、実 績コスト 1004が入力されている場合には当該実績コスト 1004に基づいて重要度を 決定し、実績コスト 1004が入力されていない場合には修正コスト 1003に基づいて重 要度を算出する。修正コスト 1003が算出されていない場合には予定コスト 1002に基 づいて重要度を判定するようにしても良い。このようにして判定された重要度は、タス ク IDに関連付けられて、タスク情報テーブル C 1001の重要度 1005に記憶される。
[0109] 続いて、送受信手段 106が、端末 101より承認画面データの送信要求を受信する と、承認タスク判定手段 1104は、承認タスクを構成する各進拔タスクが"あら力じめ設 定された重要度以上の重要度であり、且つ、進拔が遅延している進拔タスグ'に対応 する承認タスクの送信要求であるカゝ否かを判定する。
[0110] なお、 "あら力じめ設定された重要度"とは、例えば図示しない記憶手段に"重要度 A"と記憶されている場合には、重要度 A以上の進拔タスクが対象となる。また、これ 以外に、重要度判定手段 1103により判定される前の重要度をあらかじめ設定された 重要度としても良い。つまり、重要度判定手段 1103により重要度が判定された際に、 以前の重要度よりも重要度が高くなつた場合が該当する。
[0111] また、 "進拔が遅延している進拔タスグ'の判定は、例えば上記日程修正手段 112 による処理時における、 "大きな進拔のずれが生じている場合"に該当する力否かで 判定される。またこれ以外にも、単に予定日より送れた実績が入力された進拔タスクと してちよい。
[0112] 承認タスク判定手段 1104により、承認タスクを構成する各進拔タスクのうち少なくと も 1つが、 "あら力じめ設定された重要度以上の重要度であり、且つ、進拔が遅延して Vヽる進拔タスクに対応する承認タスグ'に該当すると判定された場合、画面生成手段 107は、上記判定された重要度を含む承認画面データを生成し、端末 101に送信す る。
[0113] 重要度を含む承認画面データの一例を、図 13の承認画面 1301に示す。承認画 面の、設計タスク A— 2が、上記"あら力じめ設定された重要度以上の重要度であり、 且つ、進拔が遅延している進拔タスクに対応する承認タスク"に該当すると判定され、 重要度表示 1302が、承認画面 1301の設計タスク A— 2に対応する位置に表示され ている。
[0114] 以上のように、重要度を表す表示を承認画面に付加することで、設計タスクが予定 より遅滞していること、及び当該タスクの規模が一見して明ら力となり、承認者はいつ そう正確な判断を下すことができる。
[0115] また、承認タスク判定手段 1104が、 "あら力じめ設定された重要度以上の重要度で あり、且つ、進拔が遅延している進拔タスク"に対応する承認タスクであることを判定し た際に、承認者追加手段 1105は、新たな承認者を追加するようにしても良い。
[0116] 具体的には、承認者追カ卩手段 1105は、タスク情報テーブル B531の処理順 531を 参照する。そして、処理順が最後である承認者 (ここでは承認者 IDが P00004)を取 得し、さらに、図 12の承認者テーブル 1201を参照することで、当該承認者 ID1211 に関連付けられて 、る上位承認者 ID 1212を取得する（ここでは承認者 IDが POOO 1 0)。続いて、承認者追加手段 1105は、取得された上位承認者 IDをタスク情報テー ブル B531に追加する。ここでいう上位承認者とは、例えば承認者の上司に該当する 者を指す。ただし、上司に限られるものではなぐ単に承認者を増やすのみでもよい
[0117] 図 14に、上位承認者 IDが追加されたタスク情報テーブル B1401の一例を示す。
破線 1402で示されたデータ力 上位承認者 IDに関するデータである。
[0118] 以上のように、重要度が高く且つ遅延が発生している進拔タスクに対しては、新た な承認者 (承認者の上位に該当する承認者）が承認ワークフローの承認者に追加さ れるため、その継続が精査されることになり、全体として厳重な承認が行われることに なる。また、上位承認者が追加される場合には、例えば、遅延している進拔タスクに 対して新たな経営資源 (人材)を投入する等の判断まで同時に判定可能となり、遅延 問題を早期解決に導くことができる。
産業上の利用可能性
[0119] 本発明に係るワークフローシステムは、大規模なプロジェクトの管理におけるワーク フローシステムとして有用である。

Claims

請求の範囲
[1] タスクを開始する予定日である開始予定日データとタスクを終了する予定日である 終了予定日データとに関連付けられたタスクを特定可能な 1又は複数のタスク IDと、 第一のワークフローを特定可能な第一のワークフロー IDとを関連付けて記憶する第 一のタスク情報記憶手段と、
上記 1又は複数のタスク IDと上記第一のワークフロー IDの入力を受け付けると共に 上記第一のタスク情報記憶手段に記憶する第一の登録受付手段と、
上記タスクの進拔の実績を示す進拔実績データの更新を受け付け、当該タスクのタ スク IDと関連付けて上記第一のタスク情報記憶手段に記憶する進拔受付手段と、 上記第一のワークフローの継続を承認するための 1又は複数の承認タスクを特定可 能な承認タスク IDと第二のワークフローを特定可能な第二のワークフロー IDとを関連 付けて記憶する第二のタスク情報記憶手段と、
上記 1又は複数の承認タスク IDと上記第二のワークフロー IDの入力を受け付けると 共に上記第二のタスク情報記憶手段に記憶する第二の登録受付手段と、
上記承認タスクを実施するための承認画面データの送信指示を受信した際に、当 該送信指示を受信した際に上記第一のタスク情報記憶手段に記憶されている 1又は 複数のタスクの開始予定日データと、終了予定日データと、上記更新された進拔実 績データとを取得する取得手段と、
上記取得手段が取得した開始予定日データと、終了予定日データと、進拔実績デ 一タとを含む承認画面データを生成する承認画面生成手段と、
を備えたワークフローシステム。
[2] 上記第一のタスク情報記憶手段に記憶されるタスクは、プロジェクトの進拔を管理 する進拔ワークフローを構成する進拔タスクである請求の範囲第 1項に記載のワーク フローシステム。
[3] さらに、上記進拔受付手段にて受け付けた進拔実績データに基づいて、当該進拔 実績データに対応する上記進拔タスクの新たな終了予定日を修正終了予定日デー タとして算出し、上記タスク IDと関連付けて記憶する日程修正手段を備え、
上記承認画面生成手段は、さらに上記修正終了予定日データを含む承認画面デ ータを生成する請求の範囲第 2項に記載のワークフローシステム。
[4] 上記日程修正手段は、さらに上記修正終了日の出力の対象となった進拔タスクの 終了予定日に依存する進拔タスクが存在するか否かを判定するとともに、存在する場 合には、当該依存する進拔タスクについて新たな開始予定日と新たな終了予定日と を算出し、修正開始予定日データ及び修正終了予定日データとして上記依存する 進拔タスクのタスク IDに関連付けて記憶し、
上記承認画面生成手段は、上記依存するする進拔タスクにつ!、て修正開始予定 日データ及び修正終了予定日データを含む承認画面データを生成する請求の範囲 第 3項に記載のワークフローシステム。
[5] 上記日程修正手段は、上記終了予定日と現在日付とを比較し、終了予定日から所 定日数前に該当する場合にのみ、上記修正終了予定日を算出する請求の範囲第 3 項に記載のワークフローシステム。
[6] 上記日程修正手段は、さらに上記進拔実績データがあら力じめ定められた閾値より も小さい場合にのみ、上記修正終了予定日を算出する請求の範囲第 5項に記載のヮ ークフローシステム。
[7] 上記所定日数は、上記開始予定日と上記終了予定日とより決定する予定期間とあ らカじめ定められた割合とより算出される請求の範囲第 5項に記載のワークフローシ ステム。
[8] 上記第一のタスク情報記憶手段は、上記タスク IDと当該タスク IDに対応する作業 の実施時に必要とされる予定コストデータとを関連付けて記憶すると共に、
さらに、上記進拔受付手段にて更新を受け付けた進拔実績データと、上記予定コ ストデータとに基づ 、て、当該進拔実績データに対応する上記タスクの新たな予定コ ストを修正コストデータとして算出し、上記タスク IDと関連付けて記憶するコスト修正 手段を備え、
上記承認画面生成手段は、上記修正コストデータを含む承認画面データを生成す る請求の範囲第 1項に記載のワークフローシステム。
[9] 上記第一のタスク情報記憶手段は、上記タスク IDと当該タスク IDに対応する作業 の実施時に必要とされるコストデータとを関連付けて記憶すると共に、 さらに、
上記コストデータと所定の閾値とに基づいて、タスクの重要度を判定する重要度判 定手段と、
上記判定された重要度と上記進拔受付手段にて受け付けた進拔実績データとに 基づいて、承認画面データの送信要求が、あらかじめ設定された重要度以上の重要 度であり且つ進拔が遅延しているタスクに対応する承認タスクの送信要求力否かを 判定する承認タスク判定手段とを備え、
上記承認画面生成手段は、承認タスク判定手段により、あらかじめ設定された重要 度以上の重要度であり且つ進拔が遅延しているタスクに対応する承認タスクの送信 要求であると判定された場合に、上記判定された重要度を含む承認画面データを生 成する請求の範囲第 1項に記載のワークフローシステム。
[10] 上記コストデータは、作業の実施時に必要とされる予定コストデータ、当該予定コス トデータと作業の経過状況とより修正される修正コストデータ、当該予定コストデータ と作業の実績とにより算出される実績コストデータのいずれかを含む請求の範囲第 9 項に記載のワークフローシステム。
[11] さらに、上記判定された重要度と上記進拔受付手段にて受け付けた進拔実績デー タとに基づ 、て、あら力じめ設定された重要度以上の重要度であり且つ進拔が遅延 して ヽるタスクに対応する承認タスクに、新たな承認者 IDを追加する承認者追加手 段を備える請求の範囲第 9項に記載のワークフローシステム。
[12] タスクを開始する予定日である開始予定日データとタスクを終了する予定日である 終了予定日データとに関連付けられたタスクを特定可能な 1又は複数のタスク IDと第 一のワークフローを特定可能な第一のワークフロー IDの入力を受け付けると共に当 該タスク IDと第一のワークフロー IDとを関連付けて記憶する第一の登録受付ステツ プと、
上記タスクの進拔の実績を示す進拔実績データの更新を受け付け、当該タスクのタ スク IDと関連付けて記憶する進拔受付ステップと、
上記第一のワークフローの継続を承認するための 1又は複数の承認タスクを特定可 能な承認タスク IDと第二のワークフローを特定可能な第二のワークフロー IDの入力 を受け付けて記憶する第二の登録受付ステップと、
上記承認タスクを実施するための承認画面データの送信指示を受信した際に、当 該送信指示を受信した際に上記 1又は複数のタスクの開始予定日データと、終了予 定日データと、上記更新された進拔実績データとを取得する取得ステップと、 上記取得ステップが取得した開始予定日データと、終了予定日データと、進拔実 績データとを含む承認画面データを生成する承認画面生成ステップと、
を備えたワークフローシステムの管理方法。
[13] コンピュータに、
タスクを開始する予定日である開始予定日データとタスクを終了する予定日である 終了予定日データとに関連付けられたタスクを特定可能な 1又は複数のタスク IDと第 一のワークフローを特定可能な第一のワークフロー IDの入力を受け付けると共に当 該タスク IDと第一のワークフロー IDとを関連付けて記憶する第一の登録受付ステツ プと、
上記タスクの進拔の実績を示す進拔実績データの更新を受け付け、当該タスクのタ スク IDと関連付けて記憶する進拔受付ステップと、
上記第一のワークフローの継続を承認するための 1又は複数の承認タスクを特定可 能な承認タスク IDと第二のワークフローを特定可能な第二のワークフロー IDの入力 を受け付けて記憶する第二の登録受付ステップと、
上記承認タスクを実施するための承認画面データの送信指示を受信した際に、当 該送信指示を受信した際に上記 1又は複数のタスクの開始予定日データと、終了予 定日データと、上記更新された進拔実績データとを取得する取得ステップと、 上記取得ステップが取得した開始予定日データと、終了予定日データと、進拔実 績データとを含む承認画面データを生成する承認画面生成ステップと、
を実行させるプログラム。
[14] コンピュータに、
タスクを開始する予定日である開始予定日データとタスクを終了する予定日である 終了予定日データとに関連付けられたタスクを特定可能な 1又は複数のタスク IDと第 一のワークフローを特定可能な第一のワークフロー IDの入力を受け付けると共に当 該タスク IDと第一のワークフロー IDとを関連付けて記憶する第一の登録受付ステツ プと、
上記タスクの進拔の実績を示す進拔実績データの更新を受け付け、当該タスクのタ スク IDと関連付けて記憶する進拔受付ステップと、
上記第一のワークフローの継続を承認するための 1又は複数の承認タスクを特定可 能な承認タスク IDと第二のワークフローを特定可能な第二のワークフロー IDの入力 を受け付けて記憶する第二の登録受付ステップと、
上記承認タスクを実施するための承認画面データの送信指示を受信した際に、当 該送信指示を受信した際に上記 1又は複数のタスクの開始予定日データと、終了予 定日データと、上記更新された進拔実績データとを取得する取得ステップと、 上記取得ステップが取得した開始予定日データと、終了予定日データと、進拔実 績データとを含む承認画面データを生成する承認画面生成ステップと、
を実行させるプログラムを記録したコンピュータ読み出し可能記録媒体。
PCT/JP2007/053592 2006-05-12 2007-02-27 ワークフローシステム、管理方法、プログラム及び記録媒体 WO2007132581A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2006-133423 2006-05-12
JP2006133423 2006-05-12

Publications (1)

Publication Number Publication Date
WO2007132581A1 true WO2007132581A1 (ja) 2007-11-22

Family

ID=38693682

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2007/053592 WO2007132581A1 (ja) 2006-05-12 2007-02-27 ワークフローシステム、管理方法、プログラム及び記録媒体

Country Status (1)

Country Link
WO (1) WO2007132581A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011090607A (ja) * 2009-10-26 2011-05-06 Prime Japan Co Ltd 決算業務支援システム
JP2011090459A (ja) * 2009-10-21 2011-05-06 Prime Japan Co Ltd 決算業務促進システム
JP2011090608A (ja) * 2009-10-26 2011-05-06 Prime Japan Co Ltd 決算業務支援システム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002073934A (ja) * 2000-08-29 2002-03-12 Ranseputo Kk プロジェクト管理システム
JP2002092282A (ja) * 2000-09-12 2002-03-29 Proseed Corp プロジェクト管理支援装置、プロジェクト管理支援システム、プロジェクト管理支援方法および記録媒体
JP2004164416A (ja) * 2002-11-14 2004-06-10 Anritsu Corp 開発評価装置
JP2005202862A (ja) * 2004-01-19 2005-07-28 Japan Research Institute Ltd 開発管理システム及び開発管理用プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002073934A (ja) * 2000-08-29 2002-03-12 Ranseputo Kk プロジェクト管理システム
JP2002092282A (ja) * 2000-09-12 2002-03-29 Proseed Corp プロジェクト管理支援装置、プロジェクト管理支援システム、プロジェクト管理支援方法および記録媒体
JP2004164416A (ja) * 2002-11-14 2004-06-10 Anritsu Corp 開発評価装置
JP2005202862A (ja) * 2004-01-19 2005-07-28 Japan Research Institute Ltd 開発管理システム及び開発管理用プログラム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011090459A (ja) * 2009-10-21 2011-05-06 Prime Japan Co Ltd 決算業務促進システム
JP2011090607A (ja) * 2009-10-26 2011-05-06 Prime Japan Co Ltd 決算業務支援システム
JP2011090608A (ja) * 2009-10-26 2011-05-06 Prime Japan Co Ltd 決算業務支援システム

Similar Documents

Publication Publication Date Title
JP2011191964A (ja) ワークフロー管理方法、プログラムおよびワークフロー管理装置
Johansen et al. Investigating first planning in construction
JP4705562B2 (ja) 情報処理方法
JP6835810B2 (ja) 生産管理システム、生産管理方法、および、生産管理プログラム
WO2007132581A1 (ja) ワークフローシステム、管理方法、プログラム及び記録媒体
JP2004213147A (ja) 翻訳管理装置及び翻訳管理システム
US20030135403A1 (en) Method for tracking future support engineering requests
JP6844797B2 (ja) マッチング支援システム、サーバ及びマッチング支援方法
JP2021081887A (ja) 契約書面審査支援システム、契約書面審査支援方法、及び契約書面審査支援プログラム
Zahedi et al. Adaptive minimized communication protocol based on bim
CN102467355B (zh) 信息处理设备及方法
WO2021125267A1 (ja) 生産管理システム、生産管理方法、および、生産管理プログラム
US20020010524A1 (en) Method and system for introducing a new material into a product design system
JP2007299340A (ja) 階層型ワークフローシステム
JP2008033545A (ja) リスク算出プログラム
JP2003091627A (ja) プロジェクト管理支援システムおよびプロジェクト管理支援方法
JP2010079696A (ja) 決裁装置及びプログラム
JP2010204915A (ja) 電子文書開示システム、電子文書の開示方法およびプログラム
JP2005235111A (ja) ドキュメント管理システム
JP2006119917A (ja) 工程管理支援システム、工程管理支援方法及び工程管理支援プログラム
JP7454310B1 (ja) 特許情報管理システム
JP2004287554A (ja) 電子決裁処理システムおよび電子決裁処理プログラム
US20220343430A1 (en) Computational investment propensity scoring
JP2003196474A (ja) 与信管理システム、与信管理方法およびそのプログラム
US20210326716A1 (en) Targeted probing of memory networks for knowledge base construction

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07714985

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: JP

122 Ep: pct application non-entry in european phase

Ref document number: 07714985

Country of ref document: EP

Kind code of ref document: A1