JP7445494B2 - Business support system and business support method - Google Patents

Description

The present invention relates to a business support system and a business support method, and in particular, to a business support system and a business support method suitable for supporting a person in charge who has received a job request from a superior to perform the job appropriately and quickly according to his/her ability. Regarding support systems and business support methods.

When a boss requests work to a subordinate while working in an office, the request may be made verbally or by e-mail under various circumstances.

In particular, in recent years, there has been an increase in the number of cases in which business requests are made using information processing devices and communication means such as e-mail. Communication using such information processing technology is characterized by the fact that it can be carried out quickly even with distant parties, and it also has the advantage of keeping a history of requests for work.

For example, in Patent Document 1, in order to perform schedule management and appropriate deadline management, when a business requesting party receives a request notification email regarding a requested task that has been approved by an approver, it can be viewed and/or viewed as a requested task. A system is disclosed that enables processing.

JP2018-180936A

While working in an office, when a superior makes a request to a subordinate to perform a certain task, there are many cases where the superior's instructions are vague or lack information, making it difficult for the subordinate to understand the request correctly. be done. On the other hand, even if subordinates are aware of the request, the deadline for the request may be difficult for the individual, there may be no detailed explanation of how to carry out the request, or the completed image of the request and work procedures may not be shared. In some cases, the documents are created in a different format because of the lack of information, and information about who to consult with or how to consult regarding unclear points is not provided. If unclear points are not clarified and the situation and subordinates are left unattended, the deadline will arrive unfinished and the request will be left unfinished.

This means that there is a discrepancy between the requester's understanding (conveyed = sent) and the requestee's understanding (communicated = received and understood the content), and mutual expectations are mismatched. .

The technique described in Patent Document 1 does not take into consideration how to convey the details of the request to the other party. In general, inexperienced personnel must be informed of the contents of the request in a detailed and careful literal translation, and instructions for completing the request must be provided to experienced personnel. Therefore, it is thought that instructions are often given in simple and abbreviated terms, with the assumption that there is tacit understanding or hidden language in the workplace. Patent Document 1 only expresses the job content uniformly, and does not describe expressing each job in accordance with the ability of the person in charge at the request destination. In addition, if the person in charge of the work is requested to have multiple skills or has improved his or her skills in stages, the requesting boss will adjust the details of the request each time according to the skill status of the person in charge. Considering and creating a request letter is both psychologically and time-consuming and inefficient in terms of business execution.

An object of the present invention is to, when a requesting boss makes a work request to an individual person in charge, request contents for each person in charge without requiring the effort of the requesting boss. By making it easier for the person in charge to understand that the request content is within the range that is acceptable to him/her, the person in charge can start work appropriately and quickly according to his/her own abilities. The objective is to provide a business support system and a business support method that can support compliance with goals and deadlines.

Preferably, the business support system according to the present invention is a business support system that supports the task of conveying the contents of a request from a request source to a request destination, and includes a request source terminal for inputting text of the request source, and a person in charge at the request destination. a request destination terminal that displays request content information, and a business support device that receives a text of the request content from the request source terminal, generates a text that modulates the expression of the request content, and outputs it to the request destination terminal, The task support device maintains task execution ability information regarding the person in charge, calculates the difficulty level of the request based on the text of the request content, and calculates the difficulty level of the request based on the task execution ability information of the person in charge and the request difficulty level of the request content. Based on this, by replacing words in the text of the request content, a text with a modified expression of the request content is generated.
The present invention can also be understood as a business support method executed in the business support system.

According to the present invention, when a requesting boss makes a request for work to an individual person in charge who is a request destination, an instruction task is performed in which the content of the request is rephrased into acceptable expressions according to the abilities of each person in charge. can be created for multiple people at once without expending any effort on the part of the requesting supervisor, allowing the person in charge to start work appropriately and quickly according to their own abilities, and to achieve their goals. It is possible to provide a business support system and a business support method that can support compliance with deadlines.

FIG. 1 is a configuration diagram of a business support system. FIG. 2 is a hardware/software configuration diagram of a business support device. FIG. 3 is a diagram illustrating the concept of modulation when transmitting request details. It is a figure showing an example of a person in charge registration information table. It is a figure showing an example of a person in charge ability table. It is a figure which shows an example of a login state table. It is a figure which shows an example of a request content recording table. It is a figure which shows an example of a request execution result record table. FIG. 3 is a diagram illustrating an example of a task execution ability determination table. It is a figure showing an example of a word dictionary table (part 1). It is a figure showing an example of a word dictionary table (part 2). It is a figure which shows an example of a supplementary information table. It is a figure showing an example of a closed day table. FIG. 7 is a diagram showing an example of a registered word definition table, supplementary information, and modulated output format for each request type. FIG. 2 is a sequence diagram showing a series of steps in the business support system, from the transmission of the request by the requesting boss, the modulation of the request, the implementation of the requested work by the requesting subordinate, and the monitoring of the implementation. Part 1). FIG. 2 is a sequence diagram showing a series of steps in the business support system, from the transmission of the request by the requesting boss, the modulation of the request, the implementation of the requested work by the requesting subordinate, and the monitoring of the implementation. Part 2). FIG. 2 is a sequence diagram showing a series of steps in the business support system, from the transmission of the request by the requesting boss, the modulation of the request, the implementation of the requested work by the requesting subordinate, and the monitoring of the implementation. Part 3). FIG. 2 is a sequence diagram showing a series of steps in the business support system, from the transmission of the request by the requesting boss, the modulation of the request, the implementation of the requested work by the requesting subordinate, and the monitoring of the implementation. Part 4). It is a flowchart (part 1) which shows request content modulation processing. It is a flowchart which shows request content modulation processing (part 2). It is a flowchart which shows request content modulation processing (part 3). FIG. 3 is a diagram showing an example of a pre-modulation text and a post-modulation text. FIG. 3 is a diagram showing an example of a request content modulation output format. FIG. 3 is a diagram illustrating a flow of calculating the difficulty level of request contents. FIG. 2 is a diagram illustrating a flow of calculating the business performance results (latest trends) of a client. 12 is a flowchart illustrating a process for calculating the performance performance ability of a requestee. It is a flowchart (1) which shows the word conversion process in modulation of request content. 12 is a flowchart (part 2) illustrating word conversion processing in modulating request contents. 12 is a flowchart (part 2) illustrating word conversion processing in modulating request contents. It is a figure explaining an example of word conversion in request contents. It is a figure which shows an example of a request content input screen (part 1). It is a figure which shows an example of a request content input screen (part 2). It is a figure which shows an example of a modulation result confirmation screen (part 1). It is a figure which shows an example of a modulation result confirmation screen (part 2). It is a figure which shows an example of a request content notification screen (part 1). It is a figure which shows an example of a request content notification screen (part 2). It is a figure which shows an example of a request content response screen (part 1). It is a figure which shows an example of a request content response screen (part 1). It is a figure which shows an example of a request result confirmation and evaluation screen (part 1). It is a figure which shows an example of a request result confirmation and evaluation screen (part 2). It is a figure which shows an example of a request deadline adjustment value table.

Hereinafter, each embodiment according to the present invention will be described using FIGS. 1 to 26B.
First, the configuration of the business support system will be explained using FIGS. 1 and 3.

In the business support system of this embodiment, a boss sends a request regarding work to a subordinate using an information processing device, and conveys the details of the request by voice or text.

The business support system of this embodiment has a configuration in which a request source terminal 10, a request destination terminal 20, and a business support device 100 are connected through a network 5, as shown in FIG.

The request source terminal 10 is a terminal through which the boss inputs instructions by voice or text, and is, for example, a general information processing device such as a smartphone or a PC (Personal Computer). The request destination terminal 20 is a terminal used by subordinates to confirm requests from their superiors using on-screen text or audio.

The business support device 100 is a device that changes the expression of the request from the request source in a manner that matches the ability of the subordinate of the request destination (this will be referred to as "modulation" in this specification). be.

The network 5 may be based on wired communication or wireless communication. Further, it may be a global network such as the Internet, or a local area network (LAN).

As shown in FIG. 1, the business support device 100 has a functional configuration including a request input section 101, a request content difficulty level calculation section 102, a person in charge task execution ability calculation section 103, a request sentence generation section 104, and a text-to-speech synthesis/speech synthesis/speech synthesis/speech generation section 104. It consists of a recognition conversion section 105, a request output section 106, a request deadline calculation section 107, a request content confirmation processing section 108, a request response monitoring section 109, and a storage section 110.

The request input unit 101 is a functional unit that inputs request details sent from the request terminal 101. Request content difficulty level calculation unit 102 is a functional unit that calculates the difficulty level of request content. The person-in-charge job performance calculation unit 103 is a functional unit that calculates the job performance ability of the person in charge. The request text generation unit 104 is a functional unit that generates a request text according to the person in charge. The text-to-speech synthesis/recognition conversion unit 105 has a function of performing speech recognition and converting input into text when voice is input, and performing voice synthesis when outputting the request contents in voice to the request destination terminal 20. Department. The request output unit 106 is a functional unit that outputs the modulated request content to the request destination terminal 20. The request deadline calculation unit 107 is a functional unit that calculates a request deadline according to the person in charge. The request content confirmation processing unit 108 is a functional unit that performs processing for the requester's boss to confirm the request content after modulation according to the person in charge. The response monitoring unit 109 is a functional unit that monitors whether the person in charge has fulfilled the request. The storage unit 110 is a functional unit that stores data used by the business support device 100. The storage unit 110 stores a business support information DB 120. Note that the tables included in the business support information DB 120 will be explained in detail later.

Next, the software and hardware configuration of the business support device will be explained using FIG. 2.
The hardware configuration of the business support device 100 is realized by, for example, a general information processing device such as a PC or a server computer shown in FIG. 2.

In the business support device 100, a CPU (Central Processing Unit) 202, a main storage device 204, a network I/F (InterFace) 206, a display I/F 208, an input/output I/F 210, and an auxiliary storage I/F 212 are connected by a bus. It has a similar shape.

The CPU 202 controls each part of the business support device 100, loads necessary programs into the main storage device 204, and executes them.

The main storage device 204 is usually configured with a volatile memory such as a RAM, and stores programs executed by the CPU 202 and data to be referenced.

Network I/F 206 is an interface for connecting to network 5.

Display I/F 208 is an interface for connecting a display device 220 such as an LCD (Liquid Crystal Display).

The input/output I/F 210 is an interface for connecting input/output devices. In the example of FIG. 2, a keyboard 230 and a pointing device mouse 232 are connected.

The auxiliary storage I/F 212 is an interface for connecting an auxiliary storage device such as an HDD (Hard Disk Drive) 250 or an SSD (Solid State Drive).

The HDD 250 has a large storage capacity, and stores programs for executing the present embodiment. The business support device 100 includes a request input program 261, a request content difficulty calculation program 262, a person in charge task performance calculation program 263, a request statement generation program 264, a text-to-speech synthesis/recognition conversion program 265, a request output program 266, and a request program. A deadline calculation program 267, a request content confirmation processing program 268, and a request response monitoring program 269 are installed.

Request input program 261, request content difficulty level calculation program 262, person in charge task performance calculation program 263, request statement generation program 264, text-to-speech synthesis/recognition conversion program 265, request output program 266, request deadline calculation program 267, request content The confirmation processing program 268 and the request response monitoring program 269 respectively include a request input unit 101, a request content difficulty level calculation unit 102, a person in charge job execution ability calculation unit 103, a request sentence generation unit 104, and a text-to-speech synthesis/recognition conversion unit 105. , a request output section 106, a request deadline calculation section 107, a request content confirmation processing section 108, and a request response monitoring section 109.

Next, the concept of modulation when transmitting request details in this embodiment will be explained using FIG. 3.
For example, as shown in Figure 3, the requester's boss sends the request to ``Write a weekly report. As soon as possible.'' and a deadline of ``January 20th,'' to subordinate A (veteran) and subordinate B. Suppose that you send a message to a new employee (new employee), subordinate C (directly unrelated to work), and subordinate D (section manager).

As shown in FIG. 3, the business support device 100 changes the contents of the request according to the ability and work performance of the person to whom the request is made. For those with low ability and no experience, such as newcomers, use easy-to-understand expressions. The implementation deadline will also change depending on ability and experience.

Next, the tables of the business support information DB will be explained using FIGS. 4 to 13.
The person in charge registration information table is a table in which information on the person in charge is registered, and as shown in Figure 4, it includes employee ID, name, furigana, age, gender, affiliation, department, title, contact number 1, and email address. Consists of each item.

The person in charge ability table is a table that holds the work ability of the person in charge, and as shown in Figure 5, it includes employee ID, years of service, work performance ability (latest), work performance record (latest), update date, and basic information. It consists of academic ability, processing speed, English proficiency, and product knowledge.

The login status table is a table that holds the login status of the person in charge to the network, and as shown in FIG. 7, it consists of items such as employee ID, status, and status update date and time.
The request content record table is a table that stores the content requested by the requester for each event, and as shown in Figure 7, it includes the event number, request type, request date and time, request deadline, responders (number of people), and event status. , request destination, request difficulty level, request content original text, request content modulation result, screen message notification, voice notification, and e-mail notification.

The request execution result record table is a table that holds information on the results of the request executed by the person in charge, and as shown in Figure 8, it includes the execution result record number, event number, person in charge of execution, request type, and request difficulty. It consists of the following items: date of receipt of the request, date of request response, number of retransmissions of the request, response time to the request, presence or absence of response to the request, presence or absence of request completion, and request implementation evaluation. As information on the result of the person in charge implementing the request, it is also possible to include not only whether or not the request has been implemented, but also the evaluation of the superior as an evaluation of the request implementation, and this may be used as evaluation information of the ability of the person in charge.

The task execution ability judgment table is a table for judging the task execution of the person in charge at the time of modulation, and as shown in FIG. Consists of items.

The word dictionary table is a table that holds information for processing words related to the request content at the time of modulation, and as shown in FIG. Each item string consists of a plurality of (N) word registration pairs, including the following: level 1, word expression 2, word expression 2 level, word expression 3, word expression 3 level, word expression 4, word expression 4 level.

The supplementary information table is a table that holds text added as supplementary information during modulation, and as shown in FIG. Become.

The closed day table is a table that holds information on business closed days and non-recommended days used to calculate request deadlines, and as shown in Figure 12, it includes information such as date, time zone, business type, and applicable request type. It consists of each item: code and reason for closure.

The registered word definition table for each request type is a table that holds words used during modulation, supplementary conditions, and output format conditions for each request type, and as shown in FIG. It consists of the following items: registered action number, number of registered words, registered supplementary information number, modulation output format number, and request deadline adjustment table number.

The request deadline adjustment value table is a table that holds adjustment values of date and time for adjusting the request deadline for each request type.As shown in FIG. 28, the request deadline adjustment table number, business performance level, business performance It consists of each item: ability standard, implementation deadline adjustment value (X days), implementation deadline adjustment value (Y hours), and implementation deadline reminder cycle (Z hours).

Next, the processing performed by the business support system will be explained using FIGS. 14A to 22.
First, using Figures 14A to 14D, in the business support system, we will explain the process from the sending of the request by the requesting boss to the modification of the request, the implementation of the requested work by the requesting subordinate, and the monitoring of the implementation. The series of steps will be explained.

In FIGS. 14A to 14D, the interaction of each component is described in detail, but only the main processes and general flow thereof will be explained here.

First, the requester, boss Z, starts request A (FIG. 14A, S01). Then, the request content is sent from the request source terminal 10 to the business support device 100, undergoes request content modulation processing (FIG. 14B, S02), and is transmitted to the request destination terminal 20 (FIG. 14C, S03).

Subordinates B and D, who are the request recipients, respectively check the modulated request contents and carry out the request contents (FIG. 14C).

Then, the business support device 100 recalculates the request destination's business performance ability, if necessary (FIG. 14D, S04).

Further, the business support device 100 performs a request destination response monitoring process (FIG. 14D, S05), and transmits the request contents to the request destination after a certain monitoring interval (FIG. 14D).

Next, the request content modulation process will be explained using FIGS. 15A to 15C.
Assume that there are multiple people (N people) in charge of the request destination. First, the original request text is read (S100).

Next, the difficulty level of the request is calculated (S101). Note that this process will be explained in detail later using FIG. 18.

Next, the task execution ability of the requestee is calculated (S102). Note that this process will be explained in detail later using FIG. 20.

Next, the presence or absence of experience regarding the request type is searched for in the request destination's modulation execution result table shown in FIG. 8, and is set in a flag (W) (S103).

Next, it is determined whether the request destination's ability to perform the task is higher than the request difficulty level calculated in S101 (S104).

When the task execution ability of the requestee is higher than the request difficulty level, a request expression level adjustment value is set (S105), and when the requestee's task execution ability is not higher than the request difficulty level, the request expression level to the requestee remains unchanged. (±0) (S106).

Next, it is determined whether the request destination has experienced the same request type as the request content in the past (W = 1) or not (S107), and if the request destination has not experienced the same request type as the request content in the past, The supporter information of the request destination is set to required (1) (S108), and if the same request type as the request content has been experienced in the past, the supporter information of the request destination is set to null (0) (S109). .

Next, it is determined whether the requestee's ability to perform the task for this request type is equal to or higher than the threshold for all personnel in charge, and if the requester's ability to perform the task is less than the threshold, it is determined whether the requestee's ability to perform the task for this request type is less than the threshold, and if the requestee's ability to perform the task is less than the threshold, it is determined whether the requestee's ability to perform the task for this request type is greater than or equal to the threshold for the entire person in charge. is extracted (S110). At this time, the closed day table in FIG. 12 is referred to and the closed days are excluded based on the system settings. Also, based on system settings, non-recommended dates are also excluded in order to avoid dates and times that are likely to be crowded as request deadlines (end of year, busy season, etc.) and to encourage load distribution among request types.

Next, with reference to the implementation deadline adjustment value table shown in FIG. 29, an adjustment value is set for the implementation deadline according to the request type and the job execution ability of the requestee (X days, Y hours) (S112).

When the request destination's ability to perform the task is equal to or higher than the threshold value, the request destination's execution deadline is left unchanged (±0) (S113).

Next, it is determined whether the number of requests the requestee has made in the current request type is greater than or equal to the threshold for the entire person in charge (S114), and if the number of requests experienced is less than the threshold, supplementary information is required from the requestee (1 ) (S115), and when the number of requests experienced is equal to or greater than the threshold value, supplementary information is set to zero (0) for the request destination (S116).

Next, it is determined whether or not the request completion rate of the request destination is higher than the average of all the persons in charge of this request content (S117), and if the request completion rate of the request destination is not high, the request completion rate of the request destination is Implementation procedure information is set to required (1) (S118), and when the request completion rate of the request destination is high, implementation procedure information is set to absent (0) for the request destination (S119).

Next, words are replaced in the original text of the request content (generating a paraphrase of the request text) (S120). Note that this process will be explained in detail later using FIGS. 21A to 21C and FIG. 22.

Next, based on the value of the determination flag in S120, the corresponding information is applied to a modulated output format and output as a modulated result of the request content (S121).

Next, the output modulation result of the request content is stored in the request content recording table shown in FIG.

Next, an example of a pre-modulation text and a post-modulation text will be described using FIG. 16.
As shown in FIG. 16, it is assumed that the text before modulation is "Write a weekly report. It's coming soon."

The text after modulation has no preconditions, and the default is, "Write a weekly report. Soon. The deadline for implementation is January 20th at 3:00 pm."

In the case of Subordinate B (new employee), he has little work experience, so the text after modification is ``Please fill in your work status (weekly report). Today.The deadline is January 18th at 5:00 p.m.'' .The implementation method is to add characters to the spreadsheet file on the common drive.If you have any questions, please consult Mr. A.''The support person information for carrying out the work is displayed, and the request is made. The name, point of contact, contact information, etc. of the person in charge from whom the person in charge can ask for advice are suggested.

In the case of subordinate D (new employee), "Write a weekly report. As soon as possible. The deadline is January 19th at 3:00 p.m. [Additional note] If there are any relevant members around you, please let them know." The content of the request is similar to the original text of the requester, but supplementary information according to the job responsibilities is added.

Next, an example of the request content modulation output format will be described using FIG. 17.
The request content modulation output format 300 is a template to which text is applied when modulating the request content, and includes a basic output format 310 and partial output formats 320A to 320E.

The basic output format 310 includes partial output formats 320A to 320E in the <Request body> column 310a, <Request deadline> column 310b, <Request implementation procedure> column 310c, <Supplementary> column 310d, and <Supporter information> column 310e. It has a mechanism to apply.

The character string of the request content after modulation is applied to the partial output format 320A as the request text based on the original text of the request source.

The implementation deadline is applied to the partial output format 320B as the deadline specified by the requester plus an adjustment value (date .

Implementation procedure information is applied to the partial output format 320C as an implementation procedure according to the necessity flag.

As supplementary information, corresponding supplementary information is applied to the partial output format 320D according to the necessity flag.

Applicable supplementary information is applied to the partial output format 320E as supporter information according to the necessity flag.

The request content modulation output format is variable depending on the system settings. For example, you can change the display order (A, B, C, D, E) of partial output formats within the basic output format, or change the item contents (part of the fitted item field indicated by a rectangle) displayed in the partial output format, or It is possible to arbitrarily edit and change the fixed text in .
Note that details of the data and processing will be explained later.

Next, the flow of calculating the difficulty level of the request content will be explained using FIG. 18.
Assume that the request is, "Write a weekly report. Soon."

In the next request word content extraction process, words of the request content that match the word expressions in the word dictionary table shown in FIG. 10B are extracted.
The extracted words are "weekly report" word a1, "write" word a2, and "naruhaya" word a3 (bold frame in FIG. 10B).

Next, as shown in FIG. 18, for each word expression level, a weighted average is taken by multiplying the sum of the weighted averages of actions and objects in the word dictionary table by the sum of specific weights of the guideline.

In other words, by performing weighted averaging, the difficulty of the request can be brought closer to reality from the user's perspective, and weighted averaging optimizes the difficulty of the request (the amount of work execution ability required to accomplish it). .

In this way, the reason why the request weight is applied to each action is because the ability to request from the other person changes depending on the action (reading/writing) regarding the object (weekly report), so the weighting of the request ability for this action is , to reflect the technical aspects.

For example, in the case of ``Read the weekly report,'' the task is considered easy because all you have to do is read the text and understand the meaning, but in the case of ``Write the weekly report,'' you can discard terms and expressions based on a certain purpose. This is because it is considered a difficult task to make choices and come up with sentences.

Note that, separately from the request difficulty level, a "request deadline" such as "by 3:00 PM on January 20, 2020" is set as the request content, for example. For the "request deadline," business days of the organization (for example, only during weekdays, excluding Saturdays/Sundays/holidays and special holidays) are treated as deadline setting target days. However, whether or not to include the request notification day and the request response reception day in the business day with respect to the request deadline is variable depending on the system settings. For example, assume that a requester sends out a request on January 14th (Monday) with a request deadline of January 20th (Monday). At this time, if the request response reception date is included in a business day, the request deadline is set as January 20th (Monday). However, if the condition is that the request/response reception date is not included in a business day, the business day immediately before January 20th (Monday) will be selected. Here, if January 18th (Saturday) and January 19th (Sunday) are set as closed days in the closed day table, the immediately preceding business day is set as January 17th (Friday). In this way, the request content is given to the person in charge based on the combination of the request deadline desired by the request source, the type of request content (same as the request type), and the organization's holidays, non-recommended days, etc. The implementation grace period varies.

Next, the flow of calculating the business performance performance (latest trend) of the client will be explained using FIG. 19.
First, a business performance record table as shown in FIG. 19(a) is created from the information in the request execution result record table shown in FIG. Note that the numerical values (work performance results) in the task performance results table differ depending on each task classification. Specifically, the results include the success or failure of the request (0/1), the supervisor's evaluation of the request (score: 0 to 100), the response time for the request (days/hours), the number of experiences (number of cases, presence or absence), etc. be.

Next, in each task category, the task performance results for a certain period of time (in the example below, one month) are aggregated, a section subtotal is derived, and the task performance in "task category 001" as shown in FIG. 19(b) is calculated. Obtain the interval summary of actual results.

Next, a table of moving averages (MA) of work performance results in "task category 001" as shown in FIG. 19(c) is created.
That is, for each month, a moving average (3MA) is taken using the previous three elements as calculation target values. Note that if there is no prerequisite measured value and it cannot be calculated, it is written as N/A (Not Available). This type of moving average (average of the previous three values) smoothes fluctuations in performance, and eliminates non-performance (0) and abnormal values (when the previous performance is accidentally many times higher or lower than in the past). Singularities such as these will become less likely to appear, making it possible to objectively and mechanically estimate work performance.

Next, using FIG. 20, a process for calculating a requestee's business performance performance will be described.
In this process, it is assumed that the task execution ability of the client X is calculated.
First, the request type (A) is read from the request content input data of the request source (S200).
Next, the job execution ability x (the most recent) of the client X is read from the person-in-charge ability table shown in FIG. 5 (S201).
Next, the business execution performance y of the client X for the request type A is calculated (S202).

Next, referring to the request execution result record table in FIG. 8, the execution result evaluation w of the requestee X for request type A is read (S203). This is the example shown in FIG.
Next, with reference to the request execution result record table of FIG. 8, the request response reaction time v of the requested party X for request type A is read (S204).

Next, from the read numerical values (x, y, v, w), the latest business execution ability (α) of the client X in request type A is calculated based on the following (Formula 1) (S205).

Task performance ability (α) of request destination X for request type (A) = Basic task performance ability (x) + Σ {Task performance performance (y) x (reference time - request execution reaction time (v)) x request Result evaluation (w)} ... (Formula 1)
Here, Σ means calculating the total value of all applicable elements extracted from the business support information DB (past request implementation records stored in FIGS. 5, 7, and 8).

Next, the calculation result α is stored in the person in charge ability table shown in FIG. 5 as the latest job performance ability of the target person in charge X (S206).

Next, word conversion processing in modulating request contents will be explained using FIGS. 21A to 21C. In the explanation of this word conversion process, for convenience, it is declared in advance that the concept and written expression of array variables in software programs will be used.

First, as pre-processing for word conversion processing, work variables are initialized (S300).
Next, the original request content from the requester is read (S301).
Next, the word e included in the requested original text is detected using the word dictionary table (FIG. 10A), and the total number of detected words is set as E in the working memory. Further, the number of registered words N (maximum value) of the action number to which the word e belongs is set in the working memory (S302).
Next, using the person in charge ability table (FIG. 5), the job execution ability x of the person in charge of the request destination X is read (S303).
Next, using the task performance ability determination table (FIG. 9), a word expression level reference value y corresponding to the task performance ability x of the requesting person X is set (S304).

Thereafter, each processing step shown from S305 to S318 is repeatedly performed, with the process from S305 to S319 as a loop 1 process. In loop 1, i is used as a loop variable. The maximum number of times loop 1 is processed is the total number E of detected words in the original request text.

First, the word expression level m(i) corresponding to the word e(i) is read using the word dictionary table (FIG. 10A) (S306).

Next, the value of the word expression level m(i) is set to the word expression level adjustment value Y(i). Here, the word expression level adjustment value Y(i) is a temporary variable for adjusting the word expression level. (S307).

Next, it is determined whether the word expression level adjustment value Y(i) is lower than the word expression level reference value y of the person in charge of the request destination (S308), and the word expression level adjustment value Y(i ) is low, the process moves to S309, and when the word expression level adjustment value Y(i) is equal to or higher, the process moves to S310.

When the word expression level adjustment value Y(i) is lower than the word expression level reference value y, it is assumed that the word expression of the request content is easy for the task execution ability of the person in charge of the request destination, and word replacement is determined to be unnecessary. Then, the word e(i) is set as is for the word replacement result M(i) (S309).

Next, it is determined whether all the detected words (E pieces) in the request original text have been processed, and when all the detected words (E pieces) in the request original text have been processed, the processing of loop 1 is finished, and the next Move to word (increment loop variable i) (S318).

When the word expression level adjustment value Y(i) is equal to or higher than the word expression level reference value y, a numerical value is added or subtracted from the word expression level adjustment value Y(i) according to the word expression adjustment value G (S310). That is, Y(i)=Y(i)±G. This is intended to adjust the range of comparison and adjustment at the word expression level based on the job performance ability of the person in charge of the request destination. Here, the word expression adjustment value G is variable depending on the system settings.

Next, each processing step shown in S312 to S316 is repeatedly performed, with the process from S311 to S317 as loop 2 processing. In loop 2, j is used as a loop variable. The maximum number of times loop 2 is processed is the number N of word registrations of the action number to which the word e(i) belongs in the word registration table.

First, using the word dictionary table (FIG. 10A), the first word expression level is searched from the word registration contents of the action number record to which the word e(i) belongs, and is set as k(j). (S312).

Next, it is determined whether the word expression level k(j) closest to the word expression level Y(i) exists (S313), and if the word expression level k(j) closest to the word expression level Y(i) exists, the word replacement result For M(i), a word K(j) that is associated with a word expression level k(j) is set. This is intended to replace words so that the request expression is more suitable for the task execution ability of the person in charge of the request destination. This replacement process is repeated until the number of registered words of the action number to which the word e(i) belongs reaches N in the word dictionary table. That is, the best word selection is performed (S314).

On the other hand, when the closest word expression level k(j) does not exist, a word m(i) associated with the word expression level k(i) is set for the word replacement result M(i). This is because there is no request expression on the word dictionary table that is suitable for the job execution ability of the person in charge of the request destination, and the word cannot be replaced, so the intention is to leave the word as is. In this case, loop 2 is interrupted midway (S315) and returns to loop 1, and the process moves to the next word (S318).

After completing the processing of loop 1, the word replacement results M(1) to M(E) are sequentially read from the working memory (S320), and the word replacement results M(1) to M(N) are output and saved in the final memory (S320). S321).

Next, an example of word replacement in the request content will be described using FIG. 22.
Assume that the original request from the requester is, "Write a weekly report. I'll do it soon." What this original text means is, ``Please report this week's implementation of the work that you (the person in charge of the client) are in charge of, according to the specified format and within the deadline.Please respond as soon as possible.''

In the request word content extraction process, first, as shown in FIG. 10B, words in the request content that match the "word expression" registration item in the word dictionary table are individually extracted.

That is, a specific word (a) is extracted from the original text (A) of the request content of the request source using the word expressions (nouns, verbs, adverbs) registered in the word dictionary table.

Next, the word expression level (a') of the specific word (a) and the request expression level standard (y) of the job execution ability judgment table based on the job execution ability (x) of the requestee (person in charge If the request expression level standard (y) of the request destination is lower, the request expression level of the request destination is determined from the same "action number", "action category", and "action name" record as word (a). Among the word expressions whose word expression level (b') is equal to or lower than the standard, the word expression whose word expression level is the highest is selected, and the word (b) is replaced with the word (a) in the original text.

To give a specific example, as a result of the analysis of the request execution result record table in FIG. 8, if the subordinate E's work performance ability is 150 and his behavior record is with work experience value, no word replacement occurs.

If subordinate F's work performance ability is 80, his action results include work experience points, and support, convert word a3 "naruhaya" to word b3 "as soon as possible" (word expression level: 70). .

If subordinate G's work execution ability is 100, his behavioral performance is no work experience value, and he has support, then word a1 "weekly report", word b1 "work report" (word expression level: 90), word a2 " The word b2 "write" is converted into the word b2 "fill in" (word expression level: 90), and the word a3 "naruhaya" is converted into the word b3 "as soon as possible" (word expression level: 100).

Next, the user interface of the business support system will be explained using FIGS. 23A to 26B.
First, an example of the request content input screen of the requester will be described using FIGS. 23A and 23B.

The request content input screen 500 in FIG. 23A and the request content input screen 510 in FIG. 23B are screens displayed on the request source terminal 10, and are screens on which the request source inputs the request contents. The request content input screen 500 is a screen created by a dedicated application or a web browser on a smartphone, and the request content input screen 510 is a screen created by a web browser on a PC.

The request content input screen 500 in FIG. 23A includes a client menu 501, a request type menu 502, a request destination menu 503, a request content input field 504, a request content audio input button 505, a request deadline input field 506, a request procedure input field 507, An image diagram menu 509 and an input button 520 are displayed.

The request type menu 502 and the image diagram menu 509 are selected from, for example, the items (pull-down menu) shown on the left side of FIG. 23A.

The request content input field 504 is a field for inputting the actual request content in text, and when inputting it in voice, click the request content voice input button 505. The image diagram menu 509 is a menu for selecting an image diagram, which will be explained later.
The display elements of the request content input screen 510 in FIG. 23B are also similar.

Next, an example of a modulation result confirmation screen will be described using FIGS. 24A and 24B.
The modulation result confirmation screen 700 in FIG. 24A and the modulation result confirmation screen 710 in FIG. 24B are screens displayed on the request source terminal 10, and are screens for the request source to confirm the modulated results. The modulation result confirmation screen 700 is a screen created by a dedicated application or a web browser on a smartphone, and the modulation result confirmation screen 710 is a screen created by a web browser on a PC.

The modulation result confirmation screen 700 in FIG. 24A displays a request destination menu 701, an original text display field 702, a modulation result display field 703, a correction button 704, a request button 705, and a cancel button 706.

The modulation result display field 703 is the result of modulating the text in the original text display field 702, and when the requester wants to customize it, he or she taps a modification button 704.
The same applies to the display elements of the modulation result confirmation screen 710 in FIG. 24B.

Next, an example of the request content notification screen will be described using FIGS. 25A and 25B.
The request content notification screen 800 in FIG. 25A and the request content notification screen 810 in FIG. This screen notifies the client of the text that has been modified as necessary. The request content notification screen 800 is a screen created by a dedicated application or a web browser on a smartphone, and the request content notification screen 810 is a screen created by a web browser on a PC.

A pop-up notification (banner) 801 of the request content is displayed on the request content notification screen 800 in FIG. 25A.

The same applies to the display elements of the request content notification screen 810 in FIG. 25B. Note that the notification operation and display method of the request contents differ depending on the environment such as the OS (Operating System) and applications installed on the request destination terminal.

Next, an example of the request content response screen will be described using FIGS. 26A and 26B.
The request content confirmation response screen 900 in FIG. 26A and the request content confirmation response screen 910 in FIG. This is the screen where you can confirm the request and return a response to the requester. The request content response screen 900 is a screen created by a dedicated application or a web browser on a smartphone, and the request content response screen 910 is a screen created by a web browser on a PC.

The request content response screen 900 in FIG. 26A displays a request content display field 901, a schedule setting radio button 902, an image diagram display field 903, an OK button 904, and a question/consultation button 905.

In the request content display field 901, the request content from the request source is displayed in its original text or in text that has been modified as necessary.

The image diagram display field 903 displays an image diagram related to the contents of the request. An image diagram is an illustration that represents the implementation of the request contents, and is information to encourage the person in charge who is the request destination to imagine the request contents and to start the work.

The person in charge at the request destination confirms the contents of the request, and when he/she understands the request, taps an OK button 904. When the person in charge at the request destination wants to ask a question or consult about the contents of the notified request, the person in charge taps the question/consult button 905. The person to whom questions/consultation is made may be the requester's superior, or may be a supporter (adviser) suggested by the modified text. Alternatively, it may be a specific consultation desk (call center or help desk).

The same applies to the display elements of the request content confirmation response screen 910 in FIG. 26B.
Next, an example of a method for confirming and evaluating the request result for the request content will be described using FIGS. 27A and 27B.

The request result confirmation screen 2000 in FIG. 27A and the request result confirmation screen 2100 in FIG. 27B are screens displayed on the request source terminal 10, and are screens for confirming and evaluating the results of the request requested by the request source. The request result confirmation screen 2000 is a screen created by a dedicated application or a web browser on a smartphone, and the request result confirmation screen 2100 is a screen created by a web browser on a PC.

The request result confirmation screen in Figure 27A includes request details 2001, event number 2002, request deadline 2003, status 2004, name of the person in charge of the request destination 2005, individual status 2006 of the person in charge of the request destination, and individual information for the person in charge of the request destination. A contact button 2007, an individual response information display field 2008 for the person in charge of the request destination, an individual evaluation field 2009 for the person in charge of the request destination, an OK button 2010, and a cancel button 2011 are displayed.
The same applies to the display elements of the request result confirmation screen 2100 in FIG. 26B.

When the request deadline specified in request A has passed, the business support device 100 executes request A from the log data stored in the request content record table (FIG. 7) and the request execution result record table (FIG. 8) of the business support DB. The response time and completion/non-completion information are read out, the corresponding data is re-aggregated and formatted, and the result is notified to the requesting terminal 10 as the request implementation result (FIG. 14D, S08).

The requester's boss Z objectively confirms the implementation result of the request A through the request result confirmation screen (FIGS. 27A and 27B) displayed on the requester's terminal 10. The requester's boss Z can compare the individual statuses (completed/incomplete), response times (quick/late), and deadlines (complied with/exceeded) of the person in charge of the request, so that each person in charge can respond to the request contents. The actions and results of each person are assessed, and each person in charge is evaluated and scored (Figure 27A, 2009). Here, the boss Z can also individually contact the person in charge who is the request destination, if necessary, to confirm the facts (FIG. 27A, 2007). After scoring, when the requester's boss Z taps the OK button, the scoring value is transmitted to the business support device 100 and stored in the request execution result record table (FIG. 8) of the business support DB.

By storing the scoring value of request A in the request execution result record table (Figure 8), the latest work performance performance of the person in charge of the request will be displayed for new requests (request B, request C, etc.) from the next time onward. (FIG. 19) is used as target data for calculating. Further, the calculated work performance results are also used to update the person-in-charge ability table (FIG. 5). In other words, the scoring value for request A is connected to the performance performance of the person in charge of the request, and is reflected as the basis for modifying the request content (replacing words and adjusting the request deadline) from the next time onwards, improving the accuracy of the modulation process. will be held. Through this function, it is possible to automatically and simultaneously express multiple requests appropriately for each person in charge, in line with the latest business conditions, based on the behavioral results of the person in charge at the request destination and the evaluation results of the request source. can.

As described above, according to the present embodiment, it is possible to modulate the request text and request deadline, which are the request contents of the request source, according to the abilities of each person in charge who is the request destination.

Therefore, as a requester's superior, if you create one type of request content (request body and request deadline), you can make appropriate requests to carry out the request content according to the abilities of the individual person in charge of the request destination. It is possible to automatically generate multiple types of expressions simultaneously.

As a result, in order to bridge the gap in understanding between the requester and the requestee, that is, the parties concerned, the number of times the requester and the requester had to rephrase the request multiple times depending on the individual person in charge, and the amount of time required to explain the request, were reduced. Or, check the confirmation time to supplement unclear points in the request or related information, or the waiting time (inactivity time) caused by waiting for the other party's response or reply, or track the other party who has not responded to the request. By minimizing the overall cost of business communication by reducing the number of occurrences, the frequency of occurrence, and the amount of work required for management time (follow-up) such as investigation, follow-up, etc., both the requester and the client By starting the requested work early, you can improve work efficiency.

5...Network, 10...Request source terminal, 20...Request destination terminal, 100...Business support device

Claims (11)

A business support system that supports the task of conveying the details of a request from a requester to a client,
A requester terminal for inputting the requester's text,
a request destination terminal that displays information about the request to a person in charge of the request destination;
a business support device that receives a text of the request content from the request source terminal, generates a text in which the expression of the request content is modulated, and outputs the text to the request destination terminal;
The business support device holds business execution ability information regarding the person in charge,
Calculate the difficulty level of the request based on the text of the request content,
The present invention is characterized by generating a text in which the expression of the request content is modulated by replacing words in the text of the request content based on job performance ability information of the person in charge who is the request destination and the difficulty level of the request content. Business support system. The business according to claim 1, wherein the business support device calculates a request expression level adjustment value from the request difficulty level, and replaces words in the text of the request content based on the request expression level adjustment value. support system. The business support device includes a word dictionary table that stores a word expression, a word expression level related to the word expression, one or more pairs, and a request weight for the pair in one record,
The request difficulty level is calculated by referring to the word dictionary table and taking a weighted average of the word expression level of the word expression corresponding to the word of the text of the request content and the request weight. The business support system according to claim 1, characterized in that: The work support device receives work performance record information of the person in charge of the request destination, and
2. The business support system according to claim 1, wherein information on the job execution ability of the person in charge is updated based on information on the work performance performance of the person in charge at the request destination. 4. The business support system according to claim 3, wherein the job performance performance information of the person in charge includes a request performance evaluation. The business support device is characterized in that it generates text in which the expression of the request content is modulated according to an output format that includes a variable format section consisting of a request deadline format, a request implementation procedure format , a supplementary information format, and a supporter information format. The business support system according to claim 1. The business support device retains information as to whether or not the request type of the request content has been experienced;
7. The business support system according to claim 6, wherein the text to be applied to the supporter information format is generated according to whether or not the requester has experienced the same request type as the request content of the requester. 7. The business support system according to claim 6, wherein the business support device generates a text to be applied to the request deadline format according to the job execution ability of the person in charge. The business support device retains the number of request experiences of the request content,
7. The business support system according to claim 6, wherein the text to be applied to the supplementary information format is generated according to the number of requests of the same request type as the request content of the request source. The business support device maintains a completion rate of requested work by the person in charge,
7. The business support system according to claim 6, wherein the text to be applied to the request implementation procedure format is generated in accordance with a requested work completion rate of the same request content as that of the request source. A business support method using a business support system that supports the business of conveying the contents of a request from a requester to a client,
The business support system is
A requester terminal for inputting the requester's text,
a request destination terminal that displays information about the request to a person in charge of the request destination;
It has a business support device,
a step in which the business support device receives a text of the request content from the request source terminal;
a step in which the business support device generates a text in which the expression of the request content is modulated;
the business support device outputting to the request destination terminal;
The business support device holds business execution ability information regarding the person in charge,
The step of generating text that modulates the expression of the request content is as follows:
Calculate the difficulty level of the request based on the text of the request content,
The present invention is characterized by generating a text in which the expression of the request content is modulated by replacing words in the text of the request content based on job performance ability information of the person in charge who is the request destination and the difficulty level of the request content. business support methods.

Images