JP2020064547A - Server device, client device, information processing method and program - Google Patents

Abstract

To solve the problem that progress of a work based on work result time cannot be reflected on a work plan at a midway stage of the work according to the work plan.SOLUTION: A server device manages a work plan of a user, and comprises: first storage means for storing workable time of the user; second storage means for storing work schedule time of the user; acquisition means for acquiring work result time of the user; generation means for generating the work plan obtained by distributing the stored workable time to the stored work schedule time based on an instruction for generating the work plan after a specified request point of time; and control means for displaying the work plan on display means of a client device for displaying the work plan. The generation means derives the work schedule time after the request point of time based on the work result time to the work schedule time before the instructed request point of time.SELECTED DRAWING: Figure 8

Description

  The present invention relates to a technique for supporting management of work plans.

  In recent years, using the schedule information (work schedule) and project information (work items, work man-hours) given in advance, the work plan is generated and displayed to the user, thereby reducing the load of the user's own schedule management work. Business management systems that do For example, in Patent Document 1, an action schedule (TODO work) that has to be executed although the action date and time is not specified is distinguished from the action schedule (schedule) in which the action date and time is specified in advance, and the time schedule is set. A technique for generating and displaying the arranged schedule management information is described. Further, in Patent Document 2, information on the work of the worker is registered in a database in advance, and the work is classified by comparing the information registered in the database with the input operation to the computer of the worker, and the time information is recorded. The technique for recording is described.

JP, 2005-128772, A JP, 2013-37478, A

  However, with the techniques of Patent Documents 1 and 2, it is not possible to reflect the progress status of the work based on the work actual time in the work plan in the middle of the work according to the work plan.

  A server device according to an aspect of the present invention is a server device that manages a work plan of a user, and a first storage unit that stores a workable time of the user, and a second storage unit that stores a work scheduled time of the user. A work in which the stored workable time is distributed to the stored scheduled work time based on a storage unit, an acquisition unit that acquires the work actual time of the user, and an instruction to generate a work plan after a designated request time. And a control unit for displaying the work plan on the display unit of the client device for displaying the work plan. The generation unit has a work schedule before the designated request time. It is characterized in that the scheduled work time after the requested time is derived based on the actual work time with respect to time.

  According to the present invention, the progress status of a work based on the work actual time can be reflected in the work plan in the middle of the work according to the work plan.

It is a figure which shows the structural example of a work management system. It is a figure for explaining an example of a schedule database. It is a figure for explaining a project database example. It is a figure for explaining an example of a task progress database. It is a figure for demonstrating the other example of a task progress database. It is a figure which shows the example of a display of a work plan. It is a figure which shows the other example of a display of a work plan. It is a flowchart which shows a work plan display process. It is a flow chart which shows work plan generation processing. It is a figure which shows the structural example of a work management system.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. However, the constituent elements described in this embodiment are merely examples, and are not intended to limit the scope of the present invention thereto. Further, all of the combinations of the components described in the embodiments are not necessarily essential to the means for solving the problems, within the scope of the gist of the present invention described in the claims, Various modifications and changes are possible.

[Embodiment 1]
<Business management system configuration>
FIG. 1 is a diagram showing an example of the overall configuration of a business management system 100 according to this embodiment. The business management system 100 includes a client terminal (device) 10 and a server device 30, which are communicably connected to each other via a network 20. It should be noted that the client terminal 10 and the server device 30 are not limited to a single connection configuration, and may have a plurality of connection configurations.

  The client terminal 10 is a device for performing a series of operation inputs associated with the work of the user who is the business management target of the present embodiment, and collects data indicating the work status of the user and transmits the data to the server device 30. , Display work plan according to user's request.

  The server device 30 is a device for managing a schedule and a database of a project, and specifies the work item (task) of the project by analyzing the data indicating the work status of the user transmitted from the client terminal 10. It is stored as a work record.

  The network 20 is a device for connecting the client terminal 10 and the server device 30 to each other, and transmits and receives data relating to a user's work status and work plan.

<Configuration of client terminal>
The client terminal 10 is a device realized by, for example, a general personal computer (PC) or the like. The client terminal 10 includes a communication unit 11, a control unit 12, a storage unit 13, an operation unit 14, a display unit 15, and a detection unit 16.

  The communication unit 11 is realized by a LAN or the like, and is an interface unit for transmitting / receiving data to / from the server device 30 via the network 20. In particular, the communication unit 11 of the present embodiment has a function of transmitting the operation log collected by the operation unit 14 and the action log collected by the detection unit 16 to the server device 30 as data indicating the work status of the user. .

  The control unit 12 is realized by a CPU (Central Processing Unit) or the like, and is a processing unit for processing data handled inside the client terminal 10 according to a program stored in the storage unit 13. In particular, the control unit 12 of the present embodiment has a function for controlling so as to collect and transmit data indicating the user's work status obtained from the operation unit 14 and the detection unit 16.

  The storage unit 13 is realized by a ROM (Read Only Memory), a RAM (Random Access Memory), an HDD (Hard Disk Drive), and the like. The storage unit 13 is a processing unit for storing data and programs that the control unit 12 handles inside the client terminal 10. Note that the storage unit 13 of the present embodiment may be configured to temporarily store, as data, the operation log collected by the operation unit 14 and the action log collected by the detection unit 16, for example.

  The operation unit 14 is realized by a keyboard, a mouse, and the like, and is a processing unit that receives an operation input from the user and collects an operation log accompanying the user's work as data.

  The display unit 15 is realized by a display or the like, and is a processing unit for displaying an output screen of a program such as document creation, spreadsheet calculation, schedule management, or project management that is executed in accordance with the user's work. is there.

  The detection unit 16 is realized by a camera, a microphone, etc., and is detected by the operation of the user by the operation unit 14, the operation of gazing at the display unit 15, and a conversation with another user (not shown). It is a processing unit for collecting action logs such as actions as data.

  In addition, in this embodiment, although PC was illustrated as an example of a client terminal, it is not limited to this. For example, the present invention is applied to a mobile terminal, a tablet terminal, or the like having a data collection function of an operation log accompanying a user's work, a function of detecting an action log detected according to a user's work, and a function of transmitting an operation log and an action log to the server device 30. You can also do it.

<Configuration of server device>
The server device 30 is a device realized by a control unit and a large-capacity storage unit for managing a database (hereinafter referred to as DB), and includes, for example, a DB management unit 31, a schedule DB 32, a project DB 33, and a task progress DB 34. Have. The server device 30 includes, for example, a server device equipped with a dedicated device such as a CPU, a RAM, and a ROM for analyzing a large amount of data, and a server device equipped with a dedicated device such as a HDD for storing a large amount of data. The device may have an independent structure.

  The DB management unit 31 is realized by a CPU, a RAM, a ROM, and the like, and stores data stored in the schedule DB 32, the project DB 33, and the task progress DB 34 in response to a request from a user who operates the client terminal 10. It is a processing unit for managing. The processing contents in each database will be described later with reference to FIGS.

<Schedule DB configuration>
The schedule DB 32 is realized by an HDD or the like, and is a database for storing schedule information regarding the user who is the business management target of this embodiment. FIG. 2 is a diagram for explaining an example of data stored in the schedule DB 32. FIG. 2A shows an example of a user's normal attendance schedule on a monthly basis, FIG. 2B shows an example of the working form of the user in the month shown in FIG. 2A, and FIG. 2C shows a week. An example of a schedule in which the user cannot work is shown in units.

  As shown in FIG. 2A, the schedule DB 32 holds, for example, information (information for November 2017) of the calendar 200 indicating the normal workday of the organization to which the user belongs as data. In FIG. 2A, a circle indicates a vacation day when the user cannot work. Specifically, the schedule DB 32 relates to the normal work day in November 2017, from 1st (Wed) to 3rd (Fri) of the first week, 6th (Mon) to 10th (Fri) of the second week, and the 3rd. The case where the information of the calendar 200 that is 13th (Monday) to 17th (Friday) of the week is held as data is shown. The information on the calendar 200 relates to the normal workday in November 2017, from the 20th (Mon) to the 22nd (Wed) on the 4th week, the 24th (Fri), and the 27th (Mon) to the 30th (Thurs) on the 5th week. )including. That is, the schedule DB 32 retains, as data, information on a day that can be assigned to a work by a member of the organization to which the user belongs, on a weekly basis, regarding the normal workday for one month of the organization to which the user belongs. However, the information about the normal workday held as data is not limited to a unit of one month, and may be a unit of two months or three months.

  In addition, as shown in FIG. 2B, the schedule DB 32 indicates, for example, the working hours such as the start time 201, the end time 202, or the work form 203 in which a break time is defined on the user's normal work day. The stored information is retained as data. In FIG. 2B, information in which the user's start time 201 is “9:00”, the end time 202 is “17:00”, and the work form 203 is “late work (break: 13:00 to 14:00)” Is stored as data. That is, the schedule DB 32 holds, as data, information regarding a time period in which the user can allocate work to one work day on a normal work day.

  Further, as shown in FIG. 2C, the schedule DB 32 has information indicating a scheduled time zone, such as a meeting, which the user cannot use as work time, such as a date 220, a start time 221, an end time 222, a requirement 223, and the like. The information indicating is held as data. In FIG. 2 (c), the user's work such as meetings, meetings, and outings on weekdays (November 6 (Monday) to November 10 (Friday)) 210 of the second week of November 2017 is to be performed by the user. It retains information about the time zone when it is impossible as data. Note that vacation is included as a time period during which the user cannot work. That is, the schedule DB 32 holds, as data, information regarding a time period in which the user cannot normally be assigned to work in one week of work. However, the information on the work-disabled time zone held as data is not limited to the unit of one week, and may be the unit of two weeks or one month.

  By using the data held in the schedule DB 32 as shown in FIGS. 2A to 2C, the DB management unit 31 can secure the time when the user who is the task management target of this embodiment performs the work. The net workable time can be derived.

<Project DB structure>
The project DB 33 is realized by an HDD or the like, and is a database for storing project information regarding users who are the business management targets of this embodiment. FIG. 3 is a diagram for explaining an example of data stored in the project DB 33. FIG. 3A shows an example of the relationship between the task (work item) of the project in which the user is engaged and the deadline, and FIG. 3B shows an example of the relationship between the subtask of the task shown in FIG. 3C shows another example of the relationship between the subtasks of the task shown in FIG.

  As illustrated in FIG. 3A, the project DB 33 holds, as data, information related to work items (tasks) of a project in which a user is involved, such as a task ID 300, a task name 301, and a deadline 302. FIG. 3A shows a state in which three tasks having task IDs T1, T2, and T3 are registered. Specifically, the project DB 33 holds, as the data 310, the task name 301 “task A” and the deadline 302 “Monday, November 13, 2017 17:00” regarding T1 of the task ID 300. The project DB 33 holds the task name 301 “task B” and the deadline 302 “Friday, November 10, 2017 17:00” as associated data 311 regarding T2 of the task ID 300. The project DB 33 holds, as data 312, the task name 301 “task C” and the deadline 302 “November 22, 2017 (Wednesday) 13:00” regarding T3 of the task ID 300.

  For example, when the project DB 33 receives the deadline information of the task C given the task ID of T3 as data by the operation input of the user, it can be held as the deadline data 316 updated by using the data. Specifically, regarding the deadline 302 associated with T3 of the task ID 300, the project DB 33 has the following functions. When the project DB 33 receives data 316 that is different from the currently held data (November 22, 2017 (Wednesday) 13:00) 316 by the user's operation input, The currently held data is updated to the received data 316. That is, the project DB 33 has a function of updating the task deadline 302 with the received data when the data by the user's operation input is received regarding the task deadline information.

  Further, FIGS. 3B and 3C are diagrams showing a specific example of a management table for managing each task of the data 310 to 312 in FIG. 3A in units of subtasks that constitute the task. Is. As shown in FIGS. 3B and 3C, the management table includes, for example, a task ID 300, a subtask ID 320, a subtask name 321, a planned man-hour 322, and the like. By referring to the task ID 300 common to FIG. 3A, it is possible to manage the parent-child relationship between tasks and subtasks. That is, tasks and subtasks can be managed in association with each other.

  The data 330 to 332 in FIG. 3B shows, for example, the subtask information of the user in the production department corresponding to the data 310 to 312 in FIG. 3A. That is, each subtask whose subtask ID is S1 to S9 is a work item whose required time can be accurately estimated, such as an assembly work time per assembly unit in a product mass production process. Is set.

  Regarding T1 of the task ID 300 in FIG. 3B, the project DB 33 holds it as data 330 configured by “S1”, “S2”, and “S3” of the subtask ID 320. Regarding the sub task ID 320 “S1”, the sub task name 321 “task A1” and the planned man-hour 322 “5 h (hour)” are associated. Regarding the subtask ID 320 “S2”, the subtask name 321 “task A2” and the planned man-hour 322 “5h (hour)” are associated. The subtask name 321 “task A3” and the planned man-hour 322 “5h (hour)” are associated with the subtask ID 320 “S3”.

  Further, regarding T2 of the task ID 300 of FIG. 3B, the project DB 33 holds it as data 331 composed of “S4” and “S5” of the subtask ID 320. With respect to “S4” of the subtask ID 320, a subtask name 321 “task B1” and a planned man-hour 322 “4h (hour)” are associated. With respect to “S5” of the subtask ID 320, a subtask name 321 “task B2” and a planned man-hour 322 “4h (hour)” are associated.

  Further, regarding T3 of the task ID 300 in FIG. 3B, the project DB 33 holds it as data 332 composed of “S6”, “S7”, “S8”, and “S9” of the subtask ID 320. Regarding the subtask ID 320 “S6”, the subtask name 321 “task C1” and the planned man-hour 322 “3h (hour)” are associated. Regarding the subtask ID 320 “S7”, the subtask name 321 “task C2” and the planned man-hour 322 “3h (hour)” are associated. The subtask name 321 “task C3” and the planned man-hour 322 “3h (hour)” are associated with the subtask ID 320 “S8”. Regarding the subtask ID 320 “S9”, the subtask name 321 “task C4” and the planned man-hour 322 “3h (hour)” are associated.

  The data 340 to 342 in FIG. 3C shows, for example, subtask information of the user of the development department corresponding to the data 310 to 312 in FIG. 3A. That is, each sub-task has a planned man-hour 322 set as a work item whose required time cannot be accurately estimated, such as coding and debugging work time per functional module in the software development process. is there. Here, the planned man-hours 322 may be, for example, a statistical expected value set based on the data of the actual man-hours in the past similar tasks accumulated in the organization, the years of experience of the person in charge, etc. It is also possible to set an output value based on a learning model in which the various conditions are input.

  Regarding T1 of the task ID 300 in FIG. 3C, the project DB 33 holds the data 340 composed of “S11”, “S12”, and “S13” of the subtask ID 320. Regarding the subtask ID 320 “S11”, the subtask name 321 “task A11” and the planned man-hour 322 “10 h (hour)” are associated. Regarding the subtask ID 320 “S12”, the subtask name 321 “task A12” and the planned man-hour 322 “2h (hour)” are associated. With regard to “S13” of the subtask ID 320, a subtask name 321 “task A13” and a planned man-hour 322 “3h (hour)” are associated.

  Further, regarding T2 of the task ID 300 of FIG. 3C, the project DB 33 holds it as data 341 including the subtask ID 320 of “S14” and “S15”. Regarding the subtask ID 320 “S14”, the subtask name 321 “task B11” and the planned man-hour 322 “5h (hour)” are associated. Regarding the subtask ID 320 “S15”, the subtask name 321 “task B12” and the planned man-hour 322 “3h (hour)” are associated.

  Further, regarding T3 of the task ID 300 in FIG. 3C, the project DB 33 holds it as data 342 configured by “S16”, “S17”, “S18”, and “S19” of the subtask ID 320. Regarding the subtask ID 320 “S16”, the subtask name 321 “task C11” and the planned man-hour 322 “5h (hour)” are associated. Regarding the sub task ID 320 “S17”, the sub task name 321 “task C12” and the planned man-hour 322 “2h (hour)” are associated. With respect to “S18” of the subtask ID 320, a subtask name 321 “task C13” and a planned man-hour 322 “2h (hour)” are associated. With regard to “S19” of the subtask ID 320, a subtask name 321 “task C14” and a planned man-hour 322 “3h (hour)” are associated.

<Structure of task progress DB>
The task progress DB 34 is realized by an HDD or the like, and is a database for storing task progress information regarding a user who is a task management target of the present embodiment, that is, work progress information. FIG. 4 is a diagram for explaining an example of data stored in the task progress DB 34. FIG. 4A shows the relationship between tasks and schedules and actual man-hours, FIG. 4B shows details of the planned man-hours shown in FIG. 4A, and FIG. 4C shows FIG. 4A. Details of the actual man-hours are shown.

  As shown in FIG. 4A, the task progress DB 34 includes, for example, a task ID 400, a task name 401, a planned man-hour 402, and an actual man-hour 403 for each task shown in FIG. 3A registered in the project DB 33. Manage your data. Specifically, the task progress DB 34 manages T1 of the task ID 400 as data 410 in which a task name 401 “task A”, a planned man-hour 402 “15 h (hour)”, and an actual man-hour 403 “10 h (hour)” are associated. ing. Regarding T2 of the task ID 400, the task progress DB 34 manages the task name 401 “task B”, the planned manpower 402 “8h (hours)”, and the actual manpower 403 “0h (hours)” as associated data 411. Regarding T3 of the task ID 400, the task progress DB 34 manages the task name 401 “task C”, the planned manpower 402 “12h (hour)”, and the actual manpower 403 “0h (hour)” as associated data 412.

  Further, as shown in FIG. 4B, the task progress DB 34 shows details of the work schedule of the user, which is composed of, for example, a date 420, a start time 421, an end time 422, a planned man-hour 423, a task name 424, and the like. The information shown is held as data. Here, the task name 424 in the work schedule is set by the work plan generation of this embodiment. The planned man-hour 423 of FIG. 4B corresponds to the planned man-hour 402 of FIG. 4A.

  That is, in the task progress DB 34, regarding the 9 hours out of the planned 15 hours of the task A registered in the data 410, the scheduled hours 423 include 4 hours, 1 hour, 4 hours for the work schedule data 430, 432, 434, respectively. Allocating time. Further, in the task progress DB 34, regarding the 6 hours out of the 15 hours planned for the task A registered in the data 410, the planned hours 423 include 3 hours, 1 hour, 2 hours for each of the work schedule data 436, 437, 438. Allocating time.

  In the task progress DB 34, with respect to the planned man-hours of 8 hours of the task B registered in the data 411, the planned man-hours 423 are allocated to the planned work data 431, 433, and 435 for 2 hours, 3 hours, and 3 hours, respectively.

  In the task progress DB 34, regarding the planned man-hours of the task C registered in the data 412 of 12 hours, no work schedule data is allocated to the planned man-hours 423 of the second week of November 2017.

  Further, as shown in FIG. 4C, the task progress DB 34 shows details of the work record of the user, which is composed of, for example, a date 440, a start time 441, an end time 442, an actual man-hour 443, a task name 444, and the like. The information shown is held as data. Here, the task name 444 in the work record is classified based on the output value from the learning model in which the data of the operation log or the action log collected from the client terminal 10 is input, for example. The task name 444 classification method used here can be realized using the technique of Patent Document 2, for example, and the task of the classification result together with time information such as date 440, start time 441, and end time 442. The name 444 is recorded.

  The work record data 450 to 453 shown in FIG. 4C, which are registered in the task progress DB 34, show, for example, the case where all the task names 444 are classified as the task A. As a result of totaling these, the actual man-hours 403 shown in FIG. 4A registered in the task progress DB 34 are 10 hours, 0 hours, and 0 for the data 410 to 412 with task IDs T1, T2, and T3, respectively. It's time.

  Further, FIG. 5 is a diagram for explaining an example of data stored in the task progress DB 34, which is different from FIG. FIG. 5A shows the relationship between the task and the schedule and the actual man-hours and the progress rate, FIG. 5B shows the details of the planned man-hours shown in FIG. 5A, and FIG. The details of the actual man-hours shown in () are shown.

  As shown in FIG. 5A, the task progress DB 34 has, for example, the same task ID 500, task name 501, planned man-hours 502, and actual man-hours 503 as in FIG. 4A for each task registered in the project DB 33. In addition, the data of the progress rate 504 is managed. Specifically, the task progress DB 34 manages T1 of the task ID 500 as data 510 in which a task name 501 “task A”, a planned man-hour 502 “15 h (hour)”, and an actual man-hour 503 “5 h (hour)” are associated. ing. The task progress DB 34 also manages the data 513 of the progress rate 504 “50%” regarding T1 of the task ID 500. The task progress DB 34 manages T2 of the task ID 500 as data 511 in which a task name 501 “task B”, a planned man-hour 502 “8h (hour)”, and an actual man-hour 503 “5h (hour)” are associated. The task progress DB 34 also manages the data 514 of the progress rate 504 “50%” regarding T2 of the task ID 500. The task progress DB 34 manages T3 of the task ID 500 as data 512 in which a task name 501 “task C”, a planned man-hour 502 “12h (hour)”, and an actual man-hour 503 “0h (hour)” are associated. The task progress DB 34 also manages the data 515 of the progress rate 504 “0%” regarding T3 of the task ID 500.

  Further, as shown in FIG. 5B, the task progress DB 34 shows details of the work schedule of the user, which is composed of, for example, a date 520, a start time 521, an end time 522, a planned man-hour 523, a task name 524, and the like. The information shown is held as data. Here, the task name 524 in the work schedule is set by the work plan generation of this embodiment. The planned man-hours 523 of FIG. 5B corresponds to the planned man-hours 502 of FIG. 5A.

  That is, in the task progress DB 34, regarding the 9 hours out of the scheduled hours of 15 hours of the task A registered in the data 510, the scheduled hours 523 includes 4 hours, 1 hour, 4 hours for each of the scheduled work data 530, 532, 534. Allocating time. Further, in the task progress DB 34, regarding the 6 hours out of the planned 15 hours of the task A registered in the data 510, the scheduled hours 523 includes 3 hours, 1 hour, 2 hours for each of the work schedule data 536, 537, 538. Allocating time.

  In the task progress DB 34, with respect to the planned man-hours of 8 hours of the task B registered in the data 511, the planned man-hours 523 are assigned to the planned work data 531, 533, 535 for 2 hours, 3 hours and 3 hours, respectively.

  In the task progress DB 34, regarding the planned man-hours of 12 hours of the task C registered in the data 512, no work schedule data is allocated to the planned man-hours 523 of the second week of November 2017.

  Further, as shown in FIG. 5C, the task progress DB 34 shows details of the work record of the user, which is composed of, for example, a date 540, a start time 541, an end time 542, an actual man-hour 543, a task name 544, and the like. The information shown is held as data. Here, the task name 544 in the work record is classified based on the output value from the learning model in which the data of the operation log or the action log collected from the client terminal 10 is input, for example. Note that the classification method of the task name 544 used here can be realized using the technique of Patent Document 2, for example, and the task of the classification result together with time information such as the date 540, the start time 541, and the end time 542. The name 544 is recorded.

  The work record data 550, 551, 552, and 553 shown in FIG. 5C registered in the task progress DB 34 are, for example, when the task name 544 is classified into task A, task B, task A, and task B. It is shown. As a result of totaling these, the actual man-hours 503 shown in FIG. 5A registered in the task progress DB 34 are 5 hours, 5 hours, and 0 for data 510 to 512 with task IDs T1, T2, and T3, respectively. It's time.

  Here, the progress rate 504 is reflected based on the data manually input by the user using the operation unit 14 of the client terminal 10, for example. For example, in the progress rate 504 shown in FIG. 5A, regarding the progress rate data 513, 514, and 515 with task IDs T1, T2, and T3, the progress rates manually input by the user are 50%, 50%, This shows the case where it was 0%.

<Display method of client terminal>
FIG. 6 is a diagram showing a display example of the work plan displayed on the display unit of the client terminal. FIG. 6A shows a display example of the work plan based on the work schedule, FIG. 6B shows a display example of the changed work plan based on the work schedule and actual man-hours, and FIG. 6 (a) and 6 (b) show legends related to the regions. FIGS. 6A and 6B are display examples of work plans corresponding to the actual work days 210 in the calendar 200 shown in FIG. 2A, which are information on the working hours of FIG. 2B. This is illustrated according to the legend of FIG. 6C based on the information of the scheduled time zone of FIG. 2C.

  Specifically, the upper part of FIG. 6A shows a time schedule for one day corresponding to each day of November 6th (Monday) to 10th (Friday). In the lower part of FIG. 6A, the total scheduled time of each task is shown in units of 11/6 (Monday) and 7 (Tuesday), 11/8 (Wednesday) to 10 (Friday).

  In the upper part of FIG. 6 (b), the work results of one day corresponding to each day of 11/6 (Monday) and 7 (Tuesday) and each day of 11/8 (Wednesday) to 10 (Friday) It shows the time schedule of the day. In the lower part of FIG. 6 (b), the total of the actual time of each task in units of 11/6 (Monday) and 7 (Tuesday), and the schedule of each task in units of 11/8 (Wednesday) to 10 (Friday) Shows the total time.

  That is, FIG. 6A shows a display example of the work plan at the time before the start time of 11/6 (Monday), which is the time before the user's work. On the other hand, FIG. 6B shows a display example of the work plan including the work record of the user at a time point before the start work time of Wednesday, November 8 after two days of actual work.

  For example, the user refers to the display example of the work plan in FIG. 6A to set 10 hours of the workable time in two working days of 11/6 (Monday) and 7 (Tuesday) as the scheduled work time. It is possible to visually confirm that tasks A and B were counted for 5 hours.

  In addition, for example, the user refers to the display example of the work schedule including the work record in FIG. 6B to determine 10 of the workable time in two working days of 11/6 (Mon) and 7 (Tue). It is possible to visually confirm that the time was spent as the actual work time only for the task A.

  Furthermore, for example, the user can compare and refer to the displays of FIGS. 6A and 6B to work on 10 hours of the workable time in two working days of 11/6 (Monday) and 7 (Tuesday). It is possible to visually confirm that there is a difference between the scheduled time and the actual work time. That is, for each task, the user can visually confirm that there is a discrepancy between the scheduled work time assigned to the work and the actual work time of the work. The work record time is derived from the data stored in the task progress DB 34 described with reference to FIGS. 4A and 4B, for example.

  After the above confirmation, the user can generate the work plan of FIG. 6B, for example, by instructing the generation of the work plan before the start time of Wednesday, November 8th. The work plan in FIG. 6B shows a state in which 13 hours of the workable time in the three working days of 11/8 (Wednesday), 9 (Thursday), and 10 (Friday) in FIG. 6A is redistributed. ing. In the display example of FIG. 6, for example, before the schedule change, as shown in FIG. 6A, while 10 hours were allocated to the task A and 3 hours to the task B, after the schedule was changed, As shown in FIG. 6B, the task A is redistributed for 5 hours and the task B is redistributed for 8 hours. That is, the scheduled work time after the requested time point is derived based on the actual work time with respect to the designated scheduled work time before the requested time point, and the work plan that reflects this is generated. Specifically, in consideration of the progress situation in which task A was scheduled to be secured for 5 hours but was secured for 10 hours, the remaining scheduled work time for completing the remaining work is 15 hours- It is derived that 10 hours = 5 hours, and a work plan that reflects this is generated. Further, in consideration of the progress situation in which the task B was scheduled to be secured for 5 hours but was the result of securing 0 hour, the remaining scheduled work time for completing the remaining work is 8 hours-0 hours = It is derived that it is 8 hours, and a work plan that reflects this is generated. The numerical values used to generate the work plan in FIG. 6 are examples for simplifying the description, and the same derivation is possible regardless of which numerical value is given.

  FIG. 7 is a diagram showing another display example of the work plan displayed on the display unit of the client terminal. FIG. 7A shows a display example of the work plan based on the work schedule, FIG. 7B shows a display example of the changed work plan based on the work schedule and the actual man-hours, and FIG. 7 (a) and 7 (b) show legends related to the areas.

  7 (a) and 7 (b) are other display examples of the work plan corresponding to the actual working days 210 in the calendar 200 shown in FIG. 2 (a). It is illustrated according to the legend of FIG. 7C based on the information and the information of the scheduled time zone of FIG. 2C.

  In detail, the upper part of FIG. 7A shows a time schedule for one day corresponding to each day of November 6th (Monday) to 10th (Friday). In the lower part of FIG. 7 (a), the total scheduled time of each task and the progress rate are shown in units of 11/6 (Monday) and 7 (Tuesday), 11/8 (Wednesday) to 10 (Friday). There is.

  In the upper part of FIG. 7 (b), the daily work record corresponding to each day of 11/6 (Monday) and 7 (Tuesday) and each day of 11/8 (Wednesday) to 10 (Friday) It shows the time schedule of the day. In the lower part of FIG. 7 (b), the total of the actual time of each task in units of 11/6 (Monday) and 7 (Tuesday), and the schedule of each task in units of 11/8 (Wednesday) to 10 (Friday) It shows the total time and the progress rate.

  That is, FIG. 7A shows a display example of the work plan at the time before the start time of November 6 (Monday), which is the time before the user's work. On the other hand, FIG. 7B shows a display example of the work plan including the work record of the user at a time point before the business start time on Wednesday, November 8 after two days of actual work.

  By referring to the display example of the work plan in FIG. 7A, the user sets 10 hours of the workable time in the two working days of 11/6 (Mon) and 7 (Tue) as the scheduled work time. It is possible to visually confirm that the task A and the task B are counted for 5 hours. It should be noted that the user can visually confirm on November 6th (Monday) and 7th (Tuesday) that 0 hours have been added to the task C as the scheduled work time.

  In addition, for example, the user refers to the display example of the work plan including the work record in FIG. 7B to determine 10 of the workable time in two working days of 11/6 (Monday) and 7 (Tuesday). It is possible to visually confirm that 5 hours have been spent on each of the tasks A and B as the actual work time.

  Further, for example, the user compares the display of FIGS. 7A and 7B with reference to the display of FIGS. 7A and 7B, and the work can be performed for 10 hours of the workable two days of 11/6 (Mon) and 7 (Tue). You can visually confirm that the scheduled time and the actual work time were the same. The actual work time is derived from the data stored in the task progress DB 34 described with reference to FIGS. 5A and 5B, for example.

  Further, FIG. 7A shows the progress rate for the scheduled work time, and FIG. 7B shows the progress rate for the work actual time. The progress rate with respect to the scheduled work time is derived, for example, from the ratio of (actual man-hours / planned man-hours), and as shown in FIG. 7A, the progress rate of the task A = (5 hours / 15 hours). = 33%, task B progress rate = (5 hours / 8 hours) = 62%. On the other hand, the progress rate with respect to the work actual time is, for example, reflected on the basis of the data manually input by the user at the progress rate 504 of FIG. 5A, and is shown in FIG. 7B. Thus, the progress rate of task A = 50% and the progress rate of task B = 50% can be input. The user can visually confirm that the progress rates of the tasks A and B deviate from the schedule and the actual result by comparing and referring to the displays of FIGS. 7A and 7B. In other words, as a work record for two actual work days of 11/6 (Monday) and 7 (Tuesday), task A has a progress rate of 50%, which exceeds the planned progress rate of 33%, while task B has a scheduled progress rate of 62%. It can be visually confirmed that the progress rate is less than 50%.

  After the above confirmation, the user can generate the work plan of FIG. 7B, for example, by instructing the generation of the work plan before the start time of Wednesday, November 8th. The work plan of FIG. 7B shows a state in which 13 hours of the workable time in the three working days of 11/8 (Wednesday), 9 (Thursday) and 10 (Friday) of FIG. 7A is redistributed. ing. In the display example of FIG. 7, for example, before the schedule change, as shown in FIG. 7A, while the task A includes 10 hours and the task B includes 3 hours, the schedule changes after the schedule change. As shown in FIG. 7B, the task A is redistributed for 5 hours and the task B is redistributed for 5 hours. That is, based on the work actual time and the progress status with respect to the designated work time before the designated request time, the work scheduled time after the request time is derived according to the progress status, and the work plan reflecting this is generated. Specifically, in the task A, in consideration of the progress situation in which the progress rate was 50% in 5 hours, the remaining scheduled work time for achieving the progress rate of 100% is 5 hours × ((100−50) / 50) = 5 hours is derived, and a work plan reflecting this is generated. Further, in the task B, the remaining scheduled work time for achieving the progress rate of 100% is 5 hours × ((100-50) / 50) = It is derived that it is 5 hours, and a work plan that reflects this is generated.

  Further, in response to the task A and the task B being changed to a work plan that can be carried out ahead of time, for example, a part of the work plan of the subsequent task C of 12 hours shown in FIG. It is also possible to generate. That is, for example, as shown in FIG. 7B, the task C has 3 hours out of the workable time in 3 working days of 11/8 (Wednesday), 9 (Thursday), and 10 (Friday). It is derived that the scheduled work time can be secured, and a work plan that reflects this is generated. Note that the numerical values used to generate the work plan in FIG. 7 are examples for simplifying the description, and the same derivation is possible regardless of which numerical value is given.

<Control flow>
8 and 9 are flowcharts illustrating the flow of processing executed by the DB management unit 31 of the server device 30. Specifically, FIG. 8 is a flowchart showing a procedure example of the work plan display process by the DB management unit 31 of the server device 30.

  Here, the DB management unit 31 triggers reception of operation log data or action log data indicating the work status of the user from the client terminal 10 or operation input for instructing generation and display of the work plan of the user. The process of each step is executed as. That is, the DB management unit 31 performs information processing. The processing of each step shown in the flowcharts of FIGS. 8 and 9 is stored in the RAM, ROM, etc. of the DB management unit 31, and is also executed by the CPU, etc. of the DB management unit 31. The schedule DB 32 stores in advance data regarding the user's schedule (working days, working styles, non-working hours). The project DB 33 stores in advance data regarding a user's project (duration of each task, planned man-hours). The task progress DB 34 stores in advance data regarding the user's task progress (detailed schedule and actual man-hours of each task). Hereinafter, the symbol S means a step in the flowchart.

  First, the DB management unit 31 updates the data in the schedule DB 32 described with reference to FIG. 2 (S801).

  Next, the DB management unit 31 updates the data of the project DB 33 described with reference to FIG. 3 (S802).

  Next, the DB management unit 31 updates the data of the task progress DB 34 described with reference to FIGS. 4 and 5 (S803).

  Next, the DB management unit 31 determines whether or not the display of the work plan described with reference to FIGS. 6 and 7 is requested as the operation input of the operation unit 14 in the client terminal 10 (S804). In other words, the DB management unit 31 determines whether or not an operation input for instructing the user to display the work plan has been received. If the DB management unit 31 determines that the display is requested (YES in S804), the process proceeds to S805, and if it is determined that the display is not requested (NO in S804), the process returns to S801 and the processes of S801 to S803. Repeat the process. That is, the DB management unit 31 keeps updating the data stored in the schedule DB 32, the project DB 33, and the task progress DB 34 until receiving the instruction to request the display.

  Specifically, the DB management unit 31 updates the data about the attendance schedule of the user, the working form of the user, and the work schedule of the user, which are stored in the schedule DB 32 until the display request instruction is received. Also, the DB management unit 31 updates the data regarding the task deadline of the project and the planned man-hours of the subtasks constituting the task, which are stored in the project DB 33 until the display request instruction is received. The DB management unit 31 details the planned and actual man-hours, the planned man-hours, and the actual man-hours (date, start and end time) for each task of the project stored in the task progress DB 34 until the display request instruction is received. ) Is updated.

  Next, the DB management unit 31 refers to the data stored in the schedule DB 32 and the project DB 33, and acquires information on the scheduled work time until the time when the display request instruction of S804 is accepted (S805).

  Next, the DB management unit 31 refers to the data stored in the schedule DB 32 and the task progress DB 34, and acquires information on the work actual time until the time when the display request instruction of S804 is accepted (S806).

  Next, the DB management unit 31 performs the scheduled work time until the display request instruction of S804 is received, as described in FIGS. 6A and 6B or FIGS. 7A and 7B. And the actual work time are displayed in a comparable format (S807). Specifically, for example, the actual work 2 of 11/6 (Monday) and 11/7 (Tue) shown in FIGS. 6 (a) and 6 (b), or FIGS. 7 (a) and 7 (b). It corresponds to the display contents of the scheduled work time and the actual work time for each day. This allows the user to compare and confirm the relationship between the scheduled work time and the actual work time.

  Here, the DB management unit 31 determines whether or not the generation of the work plan described with reference to FIGS. 6 and 7 is requested as the operation input of the operation unit 14 in the client terminal 10 (S808). That is, the DB management unit 31 determines whether a work plan generation request has been detected. If the DB management unit 31 determines that generation is requested (YES in S808), the process proceeds to S809, and if it is determined that generation is not requested (NO in S808), the process returns to S801 and S801 to S807. Process again.

  Next, the DB management unit 31 creates a work plan for the user who operates the client terminal 10 (S809). The details of the work plan generation processing in S809 will be described later with reference to FIG.

  Next, the DB management unit 31 performs the work before and after the change at the time when the generation request instruction in S808 is received, as described with reference to FIGS. 6A and 6B or FIGS. 7A and 7B. The relationship between the scheduled times is displayed in a comparable format (S810). Specifically, this is, for example, 11/8 (water), 11/9 (tree), 11 / (water) shown in FIGS. 6 (a) and (b), or FIGS. 7 (a) and (b). This corresponds to the display content of the scheduled work time before and after the change for the actual work day of 10 (Friday). As a result, the user can compare and confirm the relationship between the scheduled work time before and after the change.

  Next, the DB management unit 31 detects whether or not an edit input by the operation input of the operation unit 14 of the client terminal 10 has been received regarding the changed scheduled work time obtained in the work plan generation in S809 (S811). ). When the DB management unit 31 detects that the edit input is received (YES in S811), the process proceeds to S812, and when the DB management unit 31 detects that the display is ended without receiving the edit input (NO in S811), the process is performed. To S813. When the process proceeds to S812, the DB management unit 31 changes the data corresponding to the edit input, returns the process to S809, and performs the processes of S809 to S811 again. Here, the data for instructing to change the work plan edited and input by the user is stored in the task progress DB 34, and will be described with reference to FIGS. 4B and 5B, for example. The updated data is updated and stored. On the other hand, when the process proceeds to S813, the DB management unit 31 determines that the changed work plan displayed in S810 has been confirmed by the user, updates and saves the work plan, and ends this flow. .

  FIG. 9 is a flowchart showing a procedure example of a work plan generation process by the DB management unit 31 of the server device 30.

  First, the DB management unit 31 refers to the data stored in the schedule DB 32, and acquires the workable time after the request point designated by the display request instruction (S901). That is, the DB management unit 31 acquires the workable time after the start date of the generated work plan.

  Next, the DB management unit 31 refers to the data stored in the project DB 33 and the task progress DB 34, and derives the scheduled work time after the request point designated by the display request instruction (S902). That is, the DB management unit 31 derives the scheduled work time after the start date of the generated work plan. Note that the specific method of deriving the scheduled work time is as described above with reference to FIGS. 6 and 7, and thus the description thereof is omitted here.

  Next, the DB management unit 31 searches (determines) whether or not there is a workable time registered in the schedule DB 32 for each task registered in the project DB 33 within a range within the deadline 302 (S903). ). When the DB management unit 31 determines that there is workable time by the deadline (YES in S903), the process proceeds to S904, and when the DB management unit 31 determines that there is no workable time by the deadline (NO in S903), the process To S905.

  After shifting to S904, the DB management unit 31 adds the workable time. Here, the workable time may be controlled (set) so as to be secured without being divided as much as possible in units of tasks and subtasks constituting the tasks. Further, it may be controlled (set) so as to be secured in accordance with a predetermined rule such as priority order or work division availability for each task.

  After shifting to S <b> 905, the DB management unit 31 causes the display unit 15 of the client terminal 10 to display an error notification screen indicating that sufficient workable time cannot be secured by the deadline of the target task. By the error notification in S905, it becomes possible to urge the user to make a change for postponing the deadline of the schedule DB 32 or a change for allocating or deleting the task of the project DB 33 to another user. In addition, when any of the data of S801 to S803 is updated in accordance with the notification of S905, and the user again instructs the creation and display of the work plan, the DB management unit 31 displays The work plan can be generated and displayed according to the flowchart of FIG.

  Next, the DB management unit 31 determines whether or not the derivation result obtained by adding the workable time secured in S904 satisfies the work scheduled time of the target task (S906). That is, the DB management unit 31 determines whether the total workable time, which is the derivation result obtained in the process of S904, is equal to or longer than the scheduled work time of the target task. When the DB management unit 31 determines that the derivation result satisfies the scheduled work time, that is, the total workable time is equal to or longer than the scheduled work time of the target task (YES in S906), the process proceeds to S907. When the DB management unit 31 determines that the derivation result does not satisfy the scheduled work time, that is, the total workable time is less than the scheduled work time of the target task (NO in S906), the process returns to S903. The processing of S903 to S904 is performed again.

  Next, the DB management unit 31 adds the derivation result of the workable time that satisfies the scheduled work time in S906 as a work plan candidate (S907).

  Finally, the DB management unit 31 determines whether or not to search another candidate of the work plan based on a predetermined condition (generation of a candidate estimated to be the best, the number of generated candidates) described later (S908). If the DB management unit 31 determines to search for another candidate (YES in S908), it returns the process to S903, performs the processes of S903 to S907 again, and determines not to search for another candidate (NO in S908). This flow ends.

  Here, in S908, the number of candidates for the work plan used for the determination may be set in advance so as to end at the time when a single candidate estimated to be the best is generated, or within the range of constraints. It may be set in advance to end after generating a plurality of selectable candidates. Regardless of whether a single or a plurality of selectable candidates are generated, the work in which the editing including the display to the user in S810 to S812 and the operation of selecting one of the plurality of options by the user is completed. The plan is specified and saved in S813.

  As described above, according to the present embodiment, it is possible to generate and display a work plan in which the scheduled work time is updated in consideration of (reflecting) the progress status of the work based on the actual work time. That is, according to the present embodiment, for each task managed in the current work plan, the work plan considering the progress status of the work based on the result of comparison of the work actual time with the work scheduled time up to the intermediate stage of the work. Can be generated and displayed.

[Embodiment 2]
<Business management system configuration>
The task management system of the first embodiment is configured to collect the action log of the user who is the work management target by the detection unit incorporated in the client terminal. On the other hand, the business management system of this embodiment has a configuration in which the client terminal and the detection unit are independently combined.

  FIG. 10 is a diagram showing an example of the overall configuration of the task management system 100 of this embodiment. As shown in FIG. 10, the work management system 100 includes a client terminal 40, a monitoring device 50, and a server device 30, which are connected via a network 20 so that they can communicate with each other. Each of the client terminal 40, the monitoring device 50, and the server device 30 is not limited to a single connected configuration, and may have a plurality of connected configurations.

  The client terminal 40 is a device for performing a series of operation inputs associated with the work of the user who is the task management target of the present embodiment, and collects data indicating the work status of the user and sends it to the server device 30. , Display work plan according to user's request.

  The monitoring device 50 is a device for collecting a series of action logs associated with the work of the user who is the business management target of the present embodiment as data such as video and audio. In particular, the monitoring device 50 collects video and audio that cannot be collected by the client terminal 40 as data indicating the work status of the user, and then executes preprocessing for data amount compression and feature amount extraction, and performs preprocessing. The resulting data is transmitted to the server device 30.

  The server device 30 is a device for managing a work plan database, and analyzes the data indicating the work status of the user transmitted from the client terminal 40 and the monitoring device 50 to determine the work item (task) of the project. It is specified and stored as a work record.

  The network 20 is a device for connecting the client terminal 40, the monitoring device 50, and the server device 30 to each other, and transmits and receives data relating to the work status and work plan of the user.

<Configuration of client terminal>
The client terminal 40 is a device realized by, for example, a general personal computer (PC) or the like. The client terminal 40 has, for example, a communication unit 41, a control unit 42, a storage unit 43, an operation unit 44, and a display unit 45. Here, since the functional units 41 to 45 shown in FIG. 10 have the same configurations as the functional units 11 to 15 shown in FIG. 1, respectively, the description thereof will be omitted.

<Configuration of monitoring device>
The monitoring device 50 is realized by a device including a camera, a microphone, and the like. Here, the monitoring device 50 is installed in, for example, a space where a single user works, and of the data indicating the work status of the user who is the work management target, the video and audio data that cannot be collected by the client terminal 40. It may be collected and complemented. Alternatively, the monitoring device 50 is installed, for example, in a space where a plurality of users work, and after identifying the user based on the detected data such as a face image and speech sound peculiar to the user, which is the work management target, It is also possible to collect and supplement voice data.

  The monitoring device 50 has a communication unit 51, a control unit 52, a storage unit 53, and a detection unit 56.

  The communication unit 51 is realized by a LAN or the like, and is an interface unit for transmitting and receiving data to and from the server device 30 via the network 20. In particular, the communication unit 51 of the present embodiment has a function of transmitting the action log collected by the detection unit 56 to the server device 30 as data indicating the work status of the user.

  The control unit 52 is realized by a CPU (Central Processing Unit) or the like, and is a processing unit for processing data handled inside the monitoring device 50 according to a program stored in the storage unit 53. In particular, the control unit 52 of the present embodiment performs preprocessing for data amount compression and feature amount extraction on the data indicating the work status of the user obtained from the detection unit 56, and transmits it to the server device 30. It has a function for controlling to do so.

  The storage unit 53 is realized by a ROM (Read Only Memory), a RAM (Random Access Memory), an HDD (Hard Disk Drive), and the like. The storage unit 53 is a processing unit for storing data and programs that the control unit 52 handles inside the monitoring device 50. Note that the storage unit 53 of the present embodiment obtains, for example, the data indicating the work status of the user obtained from the detection unit 56 or the result of the preprocessing for extracting the feature amount of the data amount compression with respect to the data. The data may be temporarily stored.

  The detection unit 56 is realized by a camera, a microphone, or the like, and is detected by the user's work and is operated by the operation unit 44, a gaze action on the display unit 45, and a conversation with another user (not shown). It is a processing unit for collecting action logs such as actions as data.

<Configuration of server device>
The server device 30 is a device realized by a control unit for managing a database (DB) and a large-capacity storage unit. The internal configuration of the server device 30 shown in FIG. 10 is the same as that shown in FIG. Note that the internal configuration and processing flow of the server device 30 described in the first embodiment with reference to FIGS. 2 to 9 are common to the present embodiment, and a description thereof will be omitted.

  As described above, according to the present exemplary embodiment, by configuring the monitoring device 50 independent of the client terminal 40, the user who uses the client terminal 40 that does not include the detection unit that can collect the video and audio data. It is possible to provide a system for collecting and analyzing the action log of. Further, according to the present embodiment, by adopting the configuration of the monitoring device 50 independent of the client terminal 40, the number of each of the client terminal 40 and the monitoring device 50 is optimized and arranged according to the number of users and the work content. Can provide the system.

[Other Embodiments]
The present invention supplies a program that implements one or more functions of the above-described embodiments to a system or apparatus via a network or a storage medium, and one or more processors in a computer of the system or apparatus read and execute the program. It can also be realized by the processing. It can also be realized by a circuit (for example, ASIC) that realizes one or more functions.

10 client terminal 20 network 30 server device 31 DB management unit 32 schedule DB
33 Project DB
34 Task progress DB
100 Business management system

Claims (10)

A server device for managing a user's work plan,
First storage means for storing the workable time of the user,
Second storage means for storing the scheduled work time of the user;
An acquisition unit for acquiring the work record time of the user,
Generating means for generating a work plan in which the stored workable time is distributed to the stored scheduled work time based on an instruction for generating a work plan after a designated request time point;
A control unit for displaying the work plan on a display unit of the client device for displaying the work plan,
The server device, wherein the generating unit derives the scheduled work time after the requested time point based on the actual work time with respect to the scheduled work time before the specified requested time point. The acquisition unit specifies a work item based on the action of the user detected by the detection unit of the client device that detects the action of the user, and acquires a work record time corresponding to the work item. The server device according to claim 1. The acquisition unit specifies a work item based on the action of the user detected by the detection unit that detects the action of the user, and obtains a work record time corresponding to the work item. The server device according to 1. The acquisition unit acquires the work record time corresponding to the work item specified based on the operation of the user received by the operation unit of the client device that receives the operation of the user, and the work record time and the specified work record time. Acquire work progress information derived based on the scheduled work time corresponding to the work item,
The server device according to claim 1, wherein the control unit causes the display unit of the client device to display the acquired work progress information. The control means causes the display means to display the work plan indicating a schedule before the user's work and the work plan including the work record of the user on the display means in a comparable form. 5. The server device according to any one of items 4 to 4. The control means causes the display means to display the work plan before the work of the user and the work plan derived based on the work record of the user on the display means after the designated request time point in a comparable format. The server device according to any one of claims 1 to 5. Requesting means for requesting the server device to generate the work plan by allocating the stored workable time to the stored work scheduled time after the request time designated by the user;
Receiving means for receiving the work plan generated by the server device from the server device;
And a display unit for displaying the received work plan when a user's request for generating the work plan is detected. An information processing method of a server device for managing a user's work plan, comprising:
A first storing step of storing the workable time of the user;
A second storage step of storing the scheduled work time of the user;
An acquisition step of acquiring the work record time of the user,
A generation step of generating a work plan in which the stored workable time is distributed to the stored scheduled work time based on an instruction to generate a work plan after a designated request time point,
And a control step of displaying the work plan on a display unit of the client device that displays the work plan.
The information processing method of a server device, wherein in the generating step, a scheduled work time after the requested time point is derived based on a work actual time with respect to the scheduled work time before the instructed requested time point.   A program for causing a computer to function as the server device according to claim 1.   A program for causing a computer to function as the client device according to claim 7.

Images