JP2011095918A - Project planning device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a project planning device for properly determining a C.C. (critical chain), even in a project including a task having a hierarchical relation. <P>SOLUTION: The project planning device includes: an information acquisition means for receiving an input of information indicating a resource and required time of each task, an order relation of the tasks, and the hierarchical relation of the tasks; a flow diagram preparing means for determining an order of the tasks so as not to cause a resource conflict among terminal tasks, and for preparing a first flow diagram; and a critical chain determining means for determining a critical chain, for a virtual flow diagram composed of the terminal tasks and virtual nodes, using start and end points of a parent task as the virtual nodes, and for displaying an element indicating the terminal task located on the critical chain so as to be discriminated from an element not located on the critical chain, in the first flow diagram or a second flow diagram prepared from the first flow diagram. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a project planning apparatus for planning a project composed of a plurality of tasks using a computer, and in particular, automatically inserting a merging buffer when planning a project according to the theory of constraint (TOC). It relates to a project planning device that can be used.

  Medical management support described in Patent Document 1 below as a system for planning a project consisting of a plurality of tasks (work) according to the constraint theory proposed by Dr. Goldratt (hereinafter also referred to as “TOC”) There is a system. In this system, a server arranges a series of clinical actions for patients as tasks according to access from an information processing terminal, sets completion criteria, required time, and resources for each task, , Also written as “CC”). C.C. is a chain in which the task “the whole is delayed when it is delayed” is linked by the task dependency relationship (order relationship), and corresponds to the “constraint condition” in the TOC. And, as a grace period when the task is not completed within the required time, the project buffer for protecting the project from the delay of the task on the CC of the project and the project from the delay of the work or work group joining the CC For this purpose, a project network diagram for each patient is created and displayed on the display unit of the information processing terminal. When a task includes a plurality of subtasks (child tasks), subtasks can be set (see paragraph 0126 of Patent Document 1 and FIG. 32).

JP 2007-140607 A

  However, when a task has a parent-child relationship (hierarchical relationship), child tasks under different parent tasks need the same resource, or the result of a child task of a parent task can be transferred to another parent task. A child task of a task may be used, and a dependency relationship may occur even though child tasks are hierarchically irrelevant. In this way, when the task has a hierarchical relationship, a dependency relationship across the hierarchy may occur, and the dependency relationship is complicated, so in the conventional project planning system including the medical management support system, There was a problem that CC could not be determined properly.

  The present invention solves the above-described problems, and an object thereof is to provide a project planning apparatus capable of appropriately determining C.C. even for a project including tasks having a hierarchical relationship.

  The project planning device of the present invention includes an input unit and a display unit, and is used for planning a project according to the theory of constraint conditions, and is necessary for project execution in accordance with a user operation using the input unit. Information acquisition means for receiving input of information indicating the required time of each task and information indicating necessary resources, as well as information indicating the order relationship between tasks and information indicating the hierarchical relationship between tasks And based on the information indicating the required time, the information indicating the resource, the information indicating the order relationship, and the information indicating the hierarchy relationship, and according to the order relationship and the hierarchy relationship, and the hierarchy relationship The order of each task is determined so that resources do not compete between tasks that do not have lower-level tasks (hereinafter referred to as “end tasks”). The first process diagram in which elements indicating each task are arranged according to the process diagram, and a process diagram creating means for displaying on the display unit and a task having a lower level task in the hierarchical relationship (hereinafter referred to as “parent task”). A virtual node (hereinafter referred to as a “virtual node”) is defined as a virtual process diagram composed of end tasks and virtual nodes based on the order relation. A terminal task and a virtual node on the critical chain in the project are determined, and the terminal task on the critical chain is added to at least one of the first process diagram and the second process diagram created from the first process diagram. A critical chain determining means for displaying an indicating element in a manner distinguishable from an element indicating a terminal task not on the critical chain. And wherein the door.

  Here, the end task on the critical chain and the parent task whose starting point virtual node is on the critical chain as a base task, the end task that joins the base point task on the critical chain A merge buffer setting for searching an end task that is not present, setting a merge buffer immediately after the found end task, and displaying an element indicating the merge buffer in at least one of the first process diagram and the second process diagram Preferably means are provided.

  In addition, a terminal task or a virtual node that merges with a terminal task on the critical chain or a virtual node on the critical chain and searching for a terminal task or a virtual node that is not on the critical chain is searched. Immediately after the start point or end point of the parent task corresponding to the node, a merge buffer is set, and a merge buffer that displays an element indicating the merge buffer in at least one of the first process diagram and the second process diagram It is good also as providing a setting means.

  The project planning program of the present invention is for planning a project in accordance with the theory of constraint conditions. A computer including an input unit and a display unit is used as a project according to a user operation using the input unit. Receives information indicating the time required for each task and information indicating required resources, as well as information indicating the order relationship between tasks and information indicating the hierarchical relationship between tasks. Information acquisition means, based on the information indicating the required time, the information indicating the resource, the information indicating the order relationship, and the information indicating the hierarchical relationship, according to the order relationship and the hierarchical relationship, and In order to avoid resource contention between tasks that do not have lower-level tasks in the hierarchical relationship (hereinafter referred to as “end tasks”), A first process diagram in which an order is determined and an element indicating each task is arranged according to the order, and a process diagram creating means for displaying on the display unit, and a task having a lower-order task in the hierarchical relationship , “Parent task”) is defined as a virtual node (hereinafter referred to as “virtual node”), and based on the order relationship, a virtual task composed of a terminal task and a virtual node. For the target process diagram, the end task and the virtual node on the critical chain in the project are determined, and at least one of the first process diagram or the second process diagram created from the first process diagram, A critical chain displaying an element indicating a terminal task on the critical chain so as to be distinguishable from an element indicating a terminal task not on the critical chain. Characterized in that to down decision means functions as a.

  Here, the computer is a terminal task that joins the base task, with the terminal task on the critical chain and the parent task whose virtual node of the starting point is on the critical chain as a base task. An end task that is not on the critical chain is searched, a merge buffer is set immediately after the found end task, and an element indicating the merge buffer is displayed in at least one of the first process diagram and the second process diagram It is preferable to function as a merging buffer setting means.

Further, the computer is searched for a terminal task or a virtual node that does not exist on the critical chain and joins a terminal task on the critical chain or a virtual node on the critical chain. Immediately after the start point or end point of the parent task corresponding to the found virtual node, a merge buffer is set, and an element indicating the merge buffer is set in at least one of the first process diagram and the second process diagram. It is good also as functioning as a merge buffer setting means to display.

  According to the present invention, C.C. can be appropriately determined even for a project including a task having a hierarchical relationship.

It is a block block diagram of the project planning apparatus which concerns on embodiment of this invention. It is a flowchart of the process which the project planning apparatus performs. It is a continuation of the flowchart. It is an example of the network diagram creation screen of the state which the user input. It is an example of a network diagram creation screen on which a project network diagram is displayed. It is a figure for demonstrating the dependence relationship of a parent task, a child task, and a preceding task. It is a schematic diagram of the dependency relationship of FIG. In the project network diagram of FIG. 4, the tasks on C.C. are displayed in a distinguishable manner. FIG. 8 is a process chart created from the project network diagram of FIG. 7. In the process chart of FIG. 8, a merge buffer is inserted. FIG. 7 is a schematic diagram showing a portion where a merging buffer is required in FIG. FIG. 8 is a schematic diagram showing another part where a merging buffer is required in FIG. FIG. 8 is a schematic diagram showing still another portion where a merging buffer is required in FIG. FIG. 9 is a diagram in which a merge buffer is inserted immediately after the start and end points of a parent task that merges with C.C. in the process chart of FIG. It is an example of a task having a hierarchical structure in which dependencies are clearly shown. It is another example of a task having a hierarchical structure in which dependency relations are clearly specified. This is another example of a task having a hierarchical structure in which dependencies are clearly specified. It is a flowchart of the process which searches the terminal task which should insert a merge buffer by recursive process. It is a flowchart of the high-order direction search process in the process of FIGS. It is a flowchart of the lower direction search process in the process of FIGS. The dependency is clearly shown in the project network diagram of FIG. It is a flowchart of the process which searches the terminal task which should insert a merge buffer by a loop process. It is a flowchart of the lower direction search process in the process of FIGS. It is a figure for demonstrating a terminal task.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

  As shown in FIG. 1, a project planning device 3 according to the embodiment is a device for planning various projects such as product development, construction work, and software development based on the TOC. 1) and a plurality of client devices (hereinafter abbreviated as “clients”) 2 that can communicate with the server 1 by being connected to the server 1 via a communication line (intranet in the embodiment). It is configured.

  The server 1 includes one or a plurality of computers, and includes an input unit 11, a calculation / control unit 12, a storage unit 13, a communication unit 14, and a display unit 15. The server 1 is installed with an OS (operating system) and various programs such as a Web server program and a project management program that operate on the OS. The input unit 11 includes a keyboard, a mouse, and the like, and inputs various information, various commands, and the like to the calculation / control unit 12 according to user operations. The storage unit 13 includes a semiconductor memory, a hard disk device, a compact disk device, and the like, and stores project data of each project. The calculation / control unit 12 includes a CPU, a RAM that is a work area of the CPU, a ROM that stores fixed data, and the like. The communication unit 14 is a part serving as an interface for connecting the server 1 and other computers including the client 2 via a communication line. The display unit 15 is composed of a liquid crystal display or the like, and displays various screens in accordance with display commands from the calculation / control unit 12.

  The project management program creates project data based on the data such as the project name input by the user and stores it in the storage unit 13, and also stores detailed project data received from the client 2 as project data of the project. It is a program that causes the server device 1 to function so as to be added and stored in the storage unit 13.

  Each client 2 is a personal computer, and includes an input unit 21, a calculation / control unit 22, a storage unit 23, a communication unit 24, and a display unit 25, as shown in FIG. Each client 2 is installed with an OS and a program operating on the OS such as a Web browser and a project planning program. The input unit 21 includes a pointing device such as a mouse, a keyboard, and the like, and inputs various data, various commands, and the like to the calculation / control unit 22 in accordance with a user operation. The storage unit 23 includes a semiconductor memory, a hard disk device, a compact disk device, and the like. The calculation / control unit 22 includes a CPU, a RAM serving as a work area for the CPU, a ROM storing fixed data, and the like. The communication unit 24 is a part that serves as an interface when connecting the client 2 and another computer such as the server 1 via a communication line. The display unit 25 is composed of a liquid crystal display or the like, and displays various screens according to display commands from the calculation / control unit 22.

  The project planning program is for causing the client 2 to function as the above-described information acquisition means, process diagram creation means, critical chain determination means, and merging buffer setting means, and by operating according to this project planning program, The calculation / control unit 22 cooperates with the input unit 21, the storage unit 23, the communication unit 24, and the display unit 25, and the information acquisition unit, process diagram creation unit, critical chain determination unit, and merge buffer setting unit described above. Function as.

  Next, the operation of the project planning apparatus 3 will be described using the flowcharts of FIGS. In FIGS. 2-1 and 2-2, the operation performed by the user is indicated by a two-dot chain line. When a user who is a project manager starts a project management program in the server 1 and performs a predetermined operation such as clicking a predetermined button on the displayed project list screen (not shown), the server 1 A new project creation screen (not shown) on which a project name, a project leader name, and the like can be input is displayed on the display unit 15 (step S101 in FIG. 2-1). When the user inputs a project name, a project start time and an end time on the new project creation screen, and performs a predetermined registration operation such as clicking a predetermined button (S102), the server 1 receives the input data. Is created and stored in the storage unit 13 (S103).

  Next, a user who is a project planner activates a project planning program in the client 2. Then, the client 2 receives the project data from the server 1, and displays a project selection screen (not shown) that displays the project name in the project data in a selectable manner on the display unit 25 (S104, S105). When the user performs a predetermined selection operation such as project name selection on the project selection screen (S106), the client 2 creates a network diagram creation screen for creating a project network diagram for the project having the selected project name. (See FIG. 3) is displayed on the display unit 25 (S107).

  <Information Acquisition Step> As shown in FIG. 3, the network diagram creation screen creates a project network diagram by arranging task boxes T1, T2,... (When not distinguished, “task box T”), etc. It is configured to be possible. The project network is a network indicating the order relationship and the hierarchical relationship between tasks in a project, and the task box T corresponds to an element indicating a task (work) in a project network diagram showing the project network.

  FIG. 3 is a network diagram creation screen in a state where the user has already input necessary information. The network diagram creation screen that is displayed first has a goal box G in which the project name is displayed, This is a state in which one task box T with no information input is arranged on the front (left side). The goal box G indicates the goal of the project (that is, the project deadline (delivery date, deadline)).

  On the network diagram creation screen, the user clicks a task button (not shown) on the screen and then clicks an arrangement position for each task necessary for the execution of the project. By performing the operation, the task box T is arranged and connected to the goal box G or another task box T by an arrow Y. In the drawings, the arrows Y1, Y2,... Are distinguished from each other by adding a numeral after the symbol “Y”, but when they are not distinguished, they are referred to as “arrow Y”. The user arranges the task box T so as to go back from the goal box G and connects it with an arrow Y. An arrow Y connecting the task boxes T corresponds to information indicating an order relationship between tasks connected to both ends of the task box T, and tasks connected to the tip side of the arrows (in the case of arrows Y3, Y6, Y7, tasks). T8) indicates that the task connected to the base end side of the arrow (arrows Y3, Y6, Y7 is executed after the tasks T3, T6, T7, respectively) Yes.

  In the example of FIG. 3, since the task box T8 is displayed from the beginning, the task box T8 is connected to the goal box G by the arrow Y8, and the task “integration test” required immediately before completion of the project is indicated in the task box T8. Enter the information. Each task box T includes the content (name may be a name) of the task indicated in the task box T, ID (identification information), time required for execution, and information of resources required for execution (resource name and quantity). ) In the task box T8, in the task box T8, the content of the task “integrated test”, “3d” indicating 3 days as the required time, the resource name “resource B” as the information indicating the resource, and its quantity “ 1 "is entered. Note that resources include people, machines, materials, and the like. Therefore, resource names include job titles, qualification names, personal names, device names, and material names. Each task box T is configured such that a plurality of resource columns R are provided as necessary. Further, the required time is a time when the possibility of completing the task is about 50%. Further, the ID may be automatically determined.

  Next, the user places a task box T of a task that needs to be completed immediately before the task indicated by the task box T8 in front of the task box T8, and connects the task box T8 with an arrow. , Information is input to these task boxes T. In the example of FIG. 3, task boxes T3, T6, and T7 are arranged and connected to the task box T8 by arrows Y3, Y6, and Y7, respectively.

  On the other hand, when a task consists of a plurality of tasks, the latter tasks can be described as the same hierarchy without describing the former tasks. However, each of the latter tasks is a child task and the former task. A task can be described as a parent task and a task having a hierarchical relationship (parent-child relationship). The tasks having a hierarchical relationship refer to tasks including other tasks and tasks included in other tasks, the former being a parent task and the latter being a child task. The parent task is a task having a lower task in the hierarchical relationship, and the child task is a task having a higher task in the hierarchical relationship. In FIG. 3, for example, the tasks indicated by task boxes T3, T31, and T32 have a hierarchical relationship, the task indicated by task box T3 is a parent task, and the tasks indicated by task boxes T31 and T32 are child tasks. Specifically, by performing a predetermined operation using the input unit 21, the user moves the task boxes T31 and T32 of the child task below the task box T3 of the parent task as in the task box T3 of FIG. To place. As shown in FIG. 3, the task box T of the child task uses a figure and a line (here, a rectangle surrounding the child task and a dotted line connecting the rectangle and the task box T of the parent task). Are connected to the task box T. The figure and line for the connection correspond to information indicating the hierarchical relationship between tasks (parent task and child task). When there is an order relationship between child tasks included in the same parent task as in task boxes T31 and T32, the user defines the order relationship with an arrow Y. In addition, even when child tasks included in different parent tasks have an order relationship, the user defines the order relationship with an arrow Y.

  As described above, the user arranges the goal box G and each task box T as shown in FIG. 3 to define the order relationship and the hierarchical relationship between the tasks, and to the goal box G and each task box T. After inputting necessary information, a predetermined confirmation operation such as clicking a predetermined button on the screen is performed (S108).

  <Process diagram creation step> Then, the client 2 inputs the input order relationship based on the information indicating the required time of each task, the information indicating the resource, the information indicating the order relationship, and the information indicating the hierarchical relationship. The task order is determined so as to follow the order relationship indicated by the information (arrow Y) indicating that the resource does not compete between the end tasks (S109). A terminal task is a task that does not have a lower-order task in a hierarchical relationship. For example, in the example of FIG. 20, child tasks 1 to 4 exist below the parent task (subordinates), and grandchild tasks 1 and 2 exist below the child task 3, and child task 1, child task 2, and child task 4, grandchild task 1 and grandchild task 2 are end tasks. Hereinafter, a task having a hierarchical relationship is also referred to as a task having a hierarchical structure, and a task having no hierarchical relationship is also referred to as a task having no hierarchical structure. The client 2 creates a project network diagram (corresponding to the first process diagram) in which the task boxes T of each task are arranged according to the determined order, and displays it on the network diagram creation screen as shown in FIG. 4 (S110). ).

  The order relationship (dependency relationship) of tasks having a hierarchy will be described. As shown in FIG. 5, when there is a parent task including a child task (hereinafter also referred to as a “group task”), (1) a child is placed between the parent task, the tasks before and after it, and subordinate child tasks. In order to execute a task, all predecessors of the parent task must be completed. (2) To execute the successor task of the parent task, all child tasks must be completed. There is a technical dependency. Here, when there is a relationship in which the task cannot be started unless the product of the preceding task is used, the preceding task and the task are technically dependent. That is, in terms of topology, as shown in FIG. 6, it has the same structure as a virtual node (event node) E sandwiching the subnetwork S at the start point and end point of the parent task.

  In addition, even if tasks are not related to each other and have no technical dependency, dependency may occur depending on resources. In the example shown in FIG. 3, the tasks indicated by the task boxes T31, T61, and T72 at hierarchical levels that are not related to each other require the same resource A at the same time. Therefore, the client 2 determines the order of the task boxes T31, T61, and T72 according to a predetermined rule (here, the task box T on the upper side in the project network diagram is on the left), thereby competing for resources. Is solved. In other words, the task boxes T31, T61, and T72 at hierarchical positions that are not related to each other require the same resource A at the same time, and thus have a relationship that depends on each other (has an order).

  Further, the client 2 determines the order of the task boxes T other than the task boxes T31, T61, T72 by the arrow Y. Therefore, as shown in FIG. 4, the client 2 arranges the task box T61 in front of the task box T72 (left side in the project network diagram) and the task box T31 in front of the task box T61, and The project network diagram is completed by shifting the related task boxes T so that the order relationship indicated by the arrow Y does not change. Note that the order relationship due to resource contention is indicated by a dotted arrow.

  In the example of FIG. 3, the hierarchical relationship is up to two layers, but there are three or more hierarchical relationships such that the parent task includes a child task and the child task further includes a child task (that is, a grandchild task). Even in this case, the client 2 determines whether or not resources are competing for the end task (that is, the group task is expanded to the lowest task), and the contention is performed by shifting the task box T. To complete the project network diagram.

  <Critical Chain Determination Step> When the user performs a predetermined CC determination instruction operation such as clicking a predetermined button on the network diagram creation screen on which the project network diagram is displayed (S111), the client 2 targets the end task. As described above, the CC is determined based on the task order determined as described above (S112).

  C.C. (Critical Chain) is a chain in which end tasks such as “the whole is delayed when it is delayed” are linked in consideration of resource competition, and corresponds to a “constraint condition” in the TOC. That is, in this embodiment, the task on C.C. is a terminal task. A chain is a sequence (connection) of tasks ordered by task dependencies (including both technical dependencies and resource dependencies), and there are C.C. and merge chains. A merge chain is a chain that traces back from the end task that joins the CC and connects end tasks that are not on the CC (that is, ends when it encounters the end task on the CC or when there is no preceding task). Say. Note that a chain is not limited to a plurality of end tasks, and may be a single end task.

  When the start point and end point of the parent task are assumed to be a virtual node E, the client 2 determines that the end task and the node are based on the order relationship (technical dependency relationship) indicated by the arrow Y and the resource dependency relationship. For the virtual process diagram (eg, the process diagram shown in Fig. 6) composed of E, the chain that takes the longest time is CCed by tracing all the chains from the goal to the first task of the chain. To determine the end task and node E on the CC. In other words, the client 2 targets the end task (that is, decomposes (expands) the task having a hierarchical structure to the lowest layer task), treats the node E in the same row as the end task, and completes the goal. All chains are traced back to the first task of the chain, and the chain that takes the longest time is determined as CC. When there are a plurality of chains that take the longest time, C.C. is determined according to a predetermined rule. Here, the upper chain in the project network diagram is C.C.

  Thus, the client 2 determines the CC by treating the node E corresponding to the start point and end point of the group task in the same manner as the end task, and internally, information indicating which node E is on the CC. Also have. When the node E corresponding to the start point is on C.C., the start point is on C.C., and when the node E corresponding to the end point is on C.C., the end point is on C.C.

  Then, as shown in FIG. 7, the client 2 can distinguish the task box T of the end task on the CC from the task box T of the end task not on the CC by changing the color in the project network diagram. It is displayed (step S113 in FIG. 2-2). In FIG. 7, task boxes T1, T31, T61, T72, T73, and T8, in which the ground portion is shaded, are task boxes T on C.C.

  If the task box T of the parent task is on C.C. at either the start point or the end point, the task box T is displayed in a different color as with the task box T on C.C. In FIG. 7, the task box T3 has a start point and the task box T7 has an end point on C.C.

  Next, when the user performs a predetermined process table display operation such as clicking a predetermined button on the network diagram creation screen on which the project network diagram is displayed (S114), the client 2 reads the process table ( This corresponds to the second process diagram) and is displayed on the display unit 25 as shown in FIG. 8 (S115, 116). The process chart of FIG. 8 is of a type called a Gantt chart, and each task is displayed as a bar (horizontal bar) B having a length corresponding to the required time. In the figure, the symbols “B” are distinguished by adding numbers such as bars B1, B2,..., But when not distinguished, they are referred to as “bar B”. Bars B1, B2,... Correspond to task boxes T1, T2,. In addition, the parent task is indicated by a black bar B with triangles pointing downward at both ends, and the task on the CC is displayed as a diagonally striped bar B so that it can be distinguished from a task not on the CC. Is displayed. The bar B is an element indicating a task in the process chart. In addition, the order relationship between tasks input on the network diagram creation screen is indicated by a solid line arrow, and the dependency relationship between tasks among resources is indicated by a dotted line arrow.

  In addition, the client 2 determines whether each task is on the CC in the column of “on CC” in the process chart of FIG. 8, “True” if there is any, “False” if there is none. As shown. In the case of the parent task, the start point is on the left side of the column, and the end point is on the C.C. on the right side of the column.

  In the present embodiment, it is also possible to create a process chart from the project network diagram before CC determination in the state of FIG. 4, in which case CC is not displayed (bars B with diagonal stripes, (There is no indication of “True” or “False”) and a process chart is created and displayed. Then, when the user performs a predetermined CC determination instruction operation on the screen on which the process table is displayed, the client 2 determines the CC as in the case of determining CC in the project network diagram, and displays the process table in FIG. Display as shown in.

  <Confluence buffer setting step> Next, when the user performs a predetermined buffer insertion instruction operation such as clicking a predetermined button on the screen on which the CC-related process table is displayed (S117), the client 2 displays the process table. Analysis is performed to determine the insertion position and length of the buffers (confluence buffer and project buffer) (S118), and the process table in which the buffers are inserted is displayed on the display unit 25 as shown in FIG. 9 (S119). The buffer is represented by a trapezoid whose bottom is shorter than the top. Further, in the figure, the project buffer is denoted by reference symbol P, and the confluence buffer is denoted by reference symbol F and a number. Note that when the merging buffers F1, F2,... Are not distinguished, they are referred to as “merging buffer F”.

  The project buffer P is a grace time (allowance time) for protecting the project from the delay of the task on the CC of the project (that is, even if the task on the CC is delayed, the project is not delayed). Inserted between the immediately preceding task and the goal, the length is determined according to the length of CC, for example, 1/2 of the length of CC.

  The merge buffer F is a grace period for protecting the CC from the delay of the merge chain that merges with the CC (that is, even if the merge chain that merges with the CC is delayed) Is provided immediately after the task that is not on the CC, and the length of the merge buffer F depends on the length of the merge chain on which the task into which the merge buffer F is inserted is mounted, For example, it is determined to be 1/2 of the length of the merging chain.

  By the way, in a project having a hierarchical structure, C.C. may move from a middle of a parent task to a hierarchically irrelevant task, or C.C. may enter a middle of a parent task from a hierarchically irrelevant task. In the example of FIG. 8, the bars B1, B31, B61, B72, B73, and B8 indicate the tasks on the CC, but from the middle of the parent task represented by the bar B3, the parent task represented by the bar B6 The CC moves, and the CC moves from the middle of the parent task represented by the bar B6 to the middle of the parent task represented by the bar B7. That is, there may be a case where the start point and end point of the parent task are not on C.C., but the child task is on C.C.

  Hereinafter, a method for determining the insertion position of the merge buffer performed by the client 2 will be described. FIGS. 10 to 12 schematically illustrate a part where a merge buffer is required in FIG. 7 as a part of a virtual process diagram after CC determination by specifying a node E corresponding to a start point and an end point of a parent task. It is shown in the figure. 10 to 12, each node is given a number after the symbol “E” for distinction. Hereinafter, the “task box” is also simply referred to as “task”. In addition, task T and node E on C.C. are given diagonal stripes.

  In FIG. 10, the node E1 as the starting point of the parent task T3 is on the CC, and the task T2 is not itself on the CC, but joins the node E1, so immediately after the task T2, the joining buffer insertion point ( It can be judged as a meeting place. Also, CC has moved from task T31 to task T61, and the node E2 at the end of the parent task T3 is not itself on the CC, but has joined the task T8 on the CC, so the node E2 Immediately after that, it can be judged as a meeting place.

  In FIG. 11, the task T31 and the child task T61 under the parent task T6 are both on CC, but the node E3 at the starting point of the parent task T6 is not on CC. However, since the node E3 merges with the task T61 on C.C., it can be determined that the node E3 is a merge point immediately after the node E3. Also, CC has moved from task T61 to task T72, and the node E4 at the end of the parent task T6 is not itself on the CC, but has joined the task T8 on the CC, so the node E4 Immediately after that, it can be judged as a meeting place.

  Furthermore, in FIG. 12, although task T71 itself is not on C.C., it merges with task T72 on C.C., so it can be determined that the task T71 is a merge point immediately after task T71. Further, the node E6 at the end point of the parent task T7 is on C.C., and the task T74 itself is not on C.C., but since it joins the node E6, it can be determined immediately after the task T74 as a joining point.

  As described above, the insertion position of the merging buffer F can be determined by treating the start point and end point node E of the parent task in the same row as the end task. FIG. 13 shows the process network shown in FIG. 8 in which the project network diagram of FIG. 7 is represented by a Gantt chart, where the joining location is determined as described above and the joining buffer F is inserted. In FIG. 13, the merge buffer F1 is inserted immediately after the bar B2 indicating the task T2, the merge buffer F6 is inserted immediately after the bar B71 indicating the task T71, and the merge buffer F7 is inserted immediately after the bar B74 indicating the task T74. Further, merge buffer F8 is inserted immediately after the end point of bar B3 indicating task T3, and merge buffers F9 and F10 are respectively inserted immediately after the start point and end point of bar B6 indicating task T6.

  In FIG. 13, when the start point or end point of the group task merges with C.C., the merge buffer F is directly inserted immediately after that. The process chart in the state shown in FIG. 13 may be displayed on the display unit 25, but the start point and end point of the group task are virtual nodes E and are not tasks with actual operating time. It is difficult to intuitively insert the merge buffer F immediately after that. For this reason, in this embodiment, the method for determining the insertion position of the merge buffer F by handling the node E at the start point and end point of the parent task in the same row as the end task is not used, as shown in FIG. Such a process chart is not displayed. Instead, as shown in FIGS. 17-1 to 17-3, the client 2 is a terminal task that merges with a task on the CC by following a task having a hierarchical structure, and is not itself on the CC. Find something (i.e. the task into which the merge buffer F should be inserted). Then, a dependency relationship is explicitly created from the task to the task on the destination C.C., and the merge buffer F is inserted immediately after the task. Hereinafter, a method for searching for a terminal task by recursive processing and inserting a merge buffer will be described with reference to examples of FIGS. 14 to 16 and FIGS. 17-1 to 17-3. 14 to 16, as in FIGS. 10 to 12, the task T and the node E on C.C. are indicated by rectangles with diagonal stripes.

  In the example shown in FIG. 14, C.C. is connected from task T16 to task T183 which is hierarchically irrelevant. Task T183 is an end task with a triple hierarchical structure. The task T17 that precedes the uppermost parent task T18 under which the task T183 is subordinated due to the technical dependency also has a triple hierarchical structure. In this way, group tasks can be nested multiple times.

  First, as shown in FIG. 17A, the client 2 initializes <list of end tasks found> for a task on C.C. as a base point (task T183 in the example of FIG. 14) (S201). The task on the CC as the base point (hereinafter also simply referred to as “the task as the base point”) is the end task on the CC and the parent task whose start point is on the CC. Is a storage area for storing a list of found end tasks. Next, the client 2 performs a process (hereinafter referred to as “upward direction search process”) to search for a terminal task that joins in the upper direction for the task on the base point C.C. (S202), and ends the process. When the processing is finished, the end task stored in the <list of end tasks found> becomes the task into which the merge buffer is to be inserted.

  <Upward Direction Search Step> As shown in FIG. 17-2, in the upward direction search process, the client 2 joins the preceding tasks of the target task (displayed as <certain task> in the figure) in the lower direction. A process for searching for a terminal task to be performed (hereinafter referred to as “lower direction search process”) is performed (S301, 302). The predecessor task means a task that precedes due to technical dependency or resource dependency. In the example of FIG. 14, the task T183 is first targeted. However, since the task T183 has the preceding task T16, the client 2 performs the lower-level search process in step S302 for the task T16. In the lower direction search process, as will be described later, it is determined whether or not the target task has a child task in step S401, and the task T16 has no child task, so the process proceeds to step 404 and is on the CC. Since the task T16 is on the CC, it is determined NO in step 404, and the low-level search process is exited. Since task T183 has no preceding task other than task T16, the process proceeds to step S304.

  In step S304, it is determined whether the target task has a parent task. If there is no parent task, the upper direction search process is exited, and the process returns to the process shown in FIG. On the other hand, if it has a parent task, it is determined whether or not the starting point of the parent task is on the CC (S305). If it is on the CC, the upper direction search process is exited and shown in FIG. Returning to the process and finishing the process, if not on the CC, a further upward search process is performed for the parent task (S306).

  In the example of FIG. 14, since the target task T183 has a parent task T182, the client 2 determines whether or not the starting point of the parent task T182 is on the CC (S305), and the starting point of the parent task T182 Is not on the CC, further upward search processing is performed for the parent task T182 (S306). Since task T182 does not have a predecessor task, the lower-level search process is not performed, and it is determined whether or not the start point of the parent task T181 of task T182 is on the CC (S305). Further upward search processing is performed for the parent task T181 (S306). Since task T181 does not have a preceding task, it does not perform the lower direction search process, and determines whether or not the start point of the parent task T18 of task T181 is on the CC (S305). Then, further upward search processing is performed for the parent task T18 (S306). In the upper direction search process for the parent task T18, since the parent task T18 has the preceding task T17, the client 2 performs the lower direction search process for the task T17.

  <Lower Direction Search Step> As shown in FIG. 17-3, in the lower direction search processing, the client 2 determines whether or not the target task has a child task (S401). For each child task at the end, the lower direction search process is further performed (S402, 403). Note that the last child task is a task with the slowest order among the child tasks immediately below (one layer below) of the same parent task. For example, when the parent task T13 in FIG. Tasks T132 and T134. On the other hand, when there is no child task, it is determined whether or not the target task is on the CC, and only when the task is not on the CC, the task is added to the <List of found end tasks> ( S404, 405).

  In the example of FIG. 14, the task T17 that is first targeted in the lower direction search process has a child task T171 (YES in S401), so that the client 2 further performs the lower direction search process for the child task T171. (S402, 403), since the child task T171 has a child task T172 (YES in S401), the client 2 further performs a lower direction search process for the child task T172 (S402, 403), and the child task T172. Has a child task T173 (YES in S401), and further downward search processing is performed for the child task T173 (S402, 403). In the lower-level search process for the child task T173, the child task T173 has no child task (NO in S401) and is not on the CC (YES in S404), so the client 2 <finds the child task T173. To the list of end tasks> (S405), exit from the lower direction search process, and return to the upper direction search process.

  In the upper direction search process, the client 2 performs the lower direction search process for the preceding task if there is a target task that has not been subjected to the lower direction search process yet, and if not, the step is performed. The process proceeds to S304. In the example of FIG. 14, since the task preceding task T18 is only task T17, client 2 proceeds to step S304. In step S304, the client 2 determines that the target task T18 does not have a parent task, returns to the process illustrated in FIG. 17A, and ends the process. When the processing is finished, the task T173 is stored in the <list of end tasks found>.

  As described above, the client 2 acquires the task into which the merge buffer is to be inserted, and clearly shows the dependency relationship between the acquired task and the task on the C.C. serving as the base point. In the example of FIG. 14, as shown by a two-dot chain line arrow, the dependency relationship between the task T173 and the task T183 is clearly indicated.

  The client 2 obtains a task into which the merge buffer is to be inserted with respect to the task serving as the base point by the method illustrated in FIGS. In the example shown in FIG. 15, when the task T121 is used as a base point, end tasks T10 and T11 are acquired. In the example shown in FIG. 16, when the task T15 is used as a base point, the end tasks T132 and T134 are acquired. Note that the two-dot chain arrows in FIGS. 15 and 16 clearly indicate the dependency between the task as the base point and the acquired task.

  Also, according to the method shown in FIGS. 17-1 to 17-3, in the example of FIG. 7, the task T2 for the task T3 (corresponding to the parent task whose start point is on the CC) is Thus, tasks T4 and T5, task T71 for task T72, and tasks T32, T62, and T74 for task T8 are acquired as tasks to which the merge buffer is to be inserted. When the dependency relationship between the acquired task and the task on C.C. is not clearly indicated by the arrow Y on the project network diagram, the client 2 specifies the dependency relationship.

  FIG. 18 clearly shows the dependency relationship between the task acquired as the task into which the merge buffer is to be inserted and the task on the CC as the base point in the project network diagram shown in FIG. The dependency relationship between the tasks T4, T5 and the task T61, and the dependency relationship between the tasks T32, T62, T74 and the task T8, which are not present, are clearly indicated by two-dot chain arrows. Note that the dependency relationship between the task T2 and the task T3 is already clearly indicated by the arrow Y2 or the like, and therefore, the display by the two-dot chain line arrow is not performed.

  Then, the client 2 inserts the merge buffer F immediately after the end task acquired as described above. That is, as shown in FIG. 9, the merge buffers F1 to F7 are inserted. When FIG. 9 is compared with FIG. 13, the merge buffers F8, F9, F10 inserted at the start points and end points of the bars B3, B6 indicating the parent tasks T3, T6 are merged buffers F2, F3, F4, It can be seen that it has been replaced by F5.

  Returning to FIG. 2-2, when the user performs a predetermined registration operation on the client 2 (S120), the client 2 indicates the identification information of each task T, such as the project name of the goal box G, and the required time. Information, information indicating necessary resources, information indicating an order relationship between tasks T, information indicating a dependency relationship between tasks T, information on CC (identification information and order of task T and node E on CC, etc.), and The detailed data including information on the buffer (insertion position and length of the project buffer P and the merge buffer F, etc.) is transmitted to the server 1 (S121), and the server 1 converts the received detailed data into the project data of the project. It is additionally stored (stored) (S122).

  As described above, the project planning device 3 sets the start point and end point of the parent task as a virtual node E, and at the end task and the node E based on the order relationship indicated by the arrow Y and the resource dependency. Since the end task and node E on the CC are determined for the configured virtual process diagram, the most time-consuming chain is properly selected even for projects including tasks with a hierarchical structure. Can be determined. Since the element indicating the end task on C.C. is displayed in the process table so as to be distinguishable from the element indicating the end task not on C.C., C.C. can be visually shown to the user.

  Then, the terminal task on the CC and the parent task whose starting point is on the CC are used as the base point task, and the terminal task that merges with the base point task and does not exist on the CC is searched. Since the merge buffer is set immediately after the found end task, the merge buffer can be automatically inserted at an appropriate position even for a project including tasks having a hierarchical relationship. For example, even in a project in which CC moves across hierarchies, such as tasks T31, T61, and T72 in FIG. 7, as shown in the merge buffer F in FIG. A merge buffer can be inserted immediately after something that is not on the CC (ie, the end task at the end of the merge chain).

  In the above embodiment, the end task to which the merge buffer is to be inserted is searched by recursive processing. However, it is generally known that recursive processing can be replaced by loop processing. Hereinafter, a method for searching for a terminal task into which a merge buffer is to be inserted by loop processing will be described with reference to FIGS.

  The task on the C.C. serving as the base point is the end task on the C.C. and the parent task whose start point is on the C.C., as in the method of FIGS. The meaning of the preceding task is also the same as the method of FIGS. 17-1 to 17-3. First, the <list of end tasks found> is initialized (step S501 in FIG. 19-1), and the task on the C.C. serving as the base point is set as the <target task> to be processed (S502). Then, for each preceding task of a certain task, a process for searching for a terminal task that joins in a lower direction, which will be described later (hereinafter referred to as “lower direction search process”) is performed (S504, 505). Next, it is determined whether the target task has a parent task and its start point is not on the CC (S506). If YES in step S506, the target task is determined as the current target. (S507), the process returns to step S505, and if NO, the process ends. The task stored in the <list of end tasks found> at the end of processing is the end task into which the merge buffer is to be inserted.

  In the lower direction search process, the storage area <search target task list> is initialized, and the preceding task that is the current target is added to the <search target task list> (step S601 in FIG. 19-2). Then, while the <search target task list> is not empty, one task <target task> to be processed is extracted from the <search target task list> (S602, 603), and the processes shown in steps S604 to S609 ( Hereinafter, “search loop processing” is repeated.

  In the search loop process, it is determined whether or not the <target task> has a child task (S604). If so, for each child task of the <target task>, the child task is at the end of the child task hierarchy. It is determined whether or not (S606). Then, only when the child task is the last in the hierarchy of the child task, the child task is added to the <search target task list> (S607). On the other hand, if it is determined in step 604 that the <target task> has no child tasks, it is determined whether or not the <target task> is on the CC (S608), and only when it is not on the CC. Then, the <target task> is added to the <list of end tasks found> (S609).

  The method shown in FIGS. 19A and 19B can be described as follows. That is, the task on the CC that is the base point is set as the first target task, the lower direction search processing is performed for each preceding task of the target task, and then the parent task that does not have the start point on the CC continues in the upper direction. The lower direction search process of each preceding task is repeated with the parent task as a new target task. In the lower direction search process, a list of search target tasks including only the preceding task is prepared in the initial state, and the search loop process is repeated while extracting the target tasks one by one until the list becomes empty. In the search loop processing, if the target task has no child tasks, if the target task is not on the CC, it is included in the list of end tasks to join, and if the target task has child tasks, For each child task, if the child task is the last in the hierarchy where the child task exists, it is added to the search target task list.

  As described above, it is also possible to search for a terminal task into which a merge buffer is to be inserted by loop processing.

  In addition, as shown in FIGS. 17-1 to 17-3 and the methods shown in FIGS. 19-1 and 19-2, the task having a hierarchical structure is traced upward or downward to join the CC. It is not a method of searching for end tasks that are not on the CC and inserting a merge buffer immediately after that, but as described above with reference to FIGS. The merge buffer F may be inserted as shown in FIG. 13 by the method of determining the insertion position of the merge buffer by treating the points as virtual nodes in the same row as the end task.

  That is, the terminal task or virtual node E that joins the terminal task or virtual node E on the CC and that is not on the CC is searched, and the terminal task found and the parent task corresponding to the found virtual node E Immediately after the start point or the end point, a merge buffer may be set, and an element indicating the merge buffer may be displayed on at least one of the project network diagram and the Gantt chart (see FIG. 13). Even with this method, as with the methods shown in FIGS. 17-1 to 17-3 and FIGS. 19-1 and 19-2 described above, an appropriate position for a project including a task having a hierarchical structure. It is possible to insert a merging buffer.

  9 and FIG. 13, as described above, the merge buffers F3 and F4 are replaced with the merge buffer F9, the merge buffer F2 is replaced with the merge buffer F8, and the merge buffer F5 is replaced with the merge buffer F10. Even in this case, in terms of time (operational time), tasks T4, T5, T32, and T62 that are end tasks that join the CC and are not themselves on the CC (represented by bars B4, B5, B32, and B62, respectively) The merge buffer F is inserted immediately after. The length of the merging buffer F as shown in FIG. 13 is determined according to the length of the longest merging chain that merges.

  In addition, as described with reference to FIGS. 17-1 to 17-3 and FIGS. 19-1 and 19-2, a terminal task on the CC and a parent task whose start point is on the CC are used as a base task. , Means for searching for a terminal task that is a terminal task that merges with the task that is the base point and is not on the CC, and sets a merge buffer immediately after the terminal task that was found, and as described with reference to FIGS. Search for a terminal task or virtual node that does not exist on CC that joins a terminal task on CC or a virtual node on CC, and find the end task found and the parent task corresponding to the virtual node found. Immediately after the start point or the end point, the client 2 is configured to have any means for setting the merge buffer, and the user can select which means to insert the merge buffer. It may be.

  In the above embodiment, the merge buffer is inserted only in the process chart (Gantt chart). However, the merge buffer may be inserted in the project network diagram. Further, the critical chain may not be displayed on the project network diagram, but may be displayed only on the process chart. In addition, an embodiment in which only the project network diagram or only the process chart is used as the process chart can be adopted. Furthermore, the process diagram is not limited to the above, as long as it shows the process by arranging the elements indicating the tasks in order.

  In the above embodiment, the client 2 is substantially configured as the project planning device 3, but the server 1 can also be configured as the project planning device 3 by installing the project planning program in the server 1. In other words, the same project can be shared between the client 2 and the server 1 and planned. The created plan can be corrected by the client 2 or can be corrected by the server 1.

  Moreover, in the said embodiment, although the project planning apparatus 3 was comprised as a server client type, you may comprise as a stand-alone type. For example, when it is not necessary to share project data, the server 1 also performs the processing of steps S105 to 120, and if the processing of steps S104 and S121 is not performed, the server 1 is a stand-alone type project planning device. 3 On the contrary, if the processing of steps S101 to S103 and S122 is also performed by the client 2 and the processing of steps S104 and S121 is not performed, the client 2 becomes the stand-alone type project planning apparatus 3.

DESCRIPTION OF SYMBOLS 1 ... Server 2 ... Client 3 ... Project planning apparatus 21 ... Input part 25 ... Display part E ... Node F ... Merge buffer

Claims (6)

A project planning device comprising an input unit and a display unit, for planning a project according to the theory of constraints,
In response to the user's operation using the input unit, information indicating the time required for each task required for project execution, and information indicating the necessary resources, and information indicating the order relationship between tasks, And information acquisition means for receiving input of information indicating a hierarchical relationship between tasks;
Based on the information indicating the required time, the information indicating the resource, the information indicating the order relationship, and the information indicating the hierarchy relationship, the order relationship and the hierarchy relationship are followed, and the lower order in the hierarchy relationship A first process diagram in which the order of each task is determined so that resources do not compete between tasks that do not have the task (hereinafter referred to as “end task”), and elements indicating each task are arranged according to the order. And a process drawing creation means for displaying on the display unit,
The start point and end point of a task having a lower-order task in the hierarchical relationship (hereinafter referred to as “parent task”) are defined as virtual nodes (hereinafter referred to as “virtual nodes”), and based on the order relationship. , For a virtual process diagram composed of end tasks and virtual nodes, determine end tasks and virtual nodes on the critical chain in the project, and from the first process diagram or the first process diagram Critical chain determination means for displaying an element indicating the end task on the critical chain in at least one of the created second process diagrams so as to be distinguishable from an element indicating the end task not on the critical chain;
A project planning apparatus comprising: The end task on the critical chain, and the end task that joins the task that is the base point with the parent task whose starting point virtual node is on the critical chain as the base task, and that is not on the critical chain A merge buffer setting means for searching for a task, setting a merge buffer immediately after the found end task, and displaying an element indicating the merge buffer in at least one of the first process diagram and the second process diagram; The project planning apparatus according to claim 1, wherein: Search for end tasks or virtual nodes that join the end task on the critical chain or the virtual node on the critical chain that are not on the critical chain. Immediately after the start point or end point of the corresponding parent task, a merging buffer is set, and a merging buffer setting means for displaying an element indicating the merging buffer in at least one of the first process diagram and the second process diagram. The project planning apparatus according to claim 1, further comprising: A project planning program for planning a project in accordance with the theory of constraints, comprising a computer having an input unit and a display unit,
In response to the user's operation using the input unit, information indicating the time required for each task required for project execution, and information indicating the necessary resources, and information indicating the order relationship between tasks, And information acquisition means for receiving input of information indicating a hierarchical relationship between tasks,
Based on the information indicating the required time, the information indicating the resource, the information indicating the order relationship, and the information indicating the hierarchy relationship, the order relationship and the hierarchy relationship are followed, and the lower order in the hierarchy relationship A first process diagram in which the order of each task is determined so that resources do not compete between tasks that do not have the task (hereinafter referred to as “end task”), and elements indicating each task are arranged according to the order. Creating a process diagram for displaying on the display unit,
as well as,
The start point and end point of a task having a lower-order task in the hierarchical relationship (hereinafter referred to as “parent task”) are defined as virtual nodes (hereinafter referred to as “virtual nodes”), and based on the order relationship. , For a virtual process diagram composed of end tasks and virtual nodes, determine end tasks and virtual nodes on the critical chain in the project, and from the first process diagram or the first process diagram Critical chain determining means for displaying an element indicating a terminal task on the critical chain in at least one of the created second process diagrams so as to be distinguishable from an element indicating a terminal task not on the critical chain;
Project planning program characterized by functioning as The computer,
The end task on the critical chain, and the end task that joins the task that is the base point with the parent task whose starting point virtual node is on the critical chain as the base task, and that is not on the critical chain Functions as a merge buffer setting means for searching for a task, setting a merge buffer immediately after the found end task, and displaying an element indicating the merge buffer in at least one of the first process diagram and the second process diagram The project planning program according to claim 4, wherein: The computer,
Search for end tasks or virtual nodes that join the end task on the critical chain or the virtual node on the critical chain that are not on the critical chain. Immediately after the start point or end point of the corresponding parent task, a merging buffer is set, and a merging buffer setting means for displaying an element indicating the merging buffer in at least one of the first process diagram and the second process diagram. The project planning program according to claim 4, wherein

Images