JP2020102064A - Automatic instruction system, method and program - Google Patents

Abstract

To provide an automatic instruction system that monitors a status of a ticket.SOLUTION: An automatic instruction system includes: a request registration system that registers a request related to work from a customer; a ticket action system that allocates the request to a person in charge according to a skill of the person in charge for the work, and generates a ticket on which order of the work is described; and a ticket workflow system that executes a workflow on the basis of the ticket. The ticket action system includes a monitoring unit that monitors a status of the ticket executed by the ticket workflow system on the basis of the ticket.SELECTED DRAWING: Figure 1

Description

The present invention relates to a work automatic instruction system, method, and program for continuously performing maintenance work so that a constructed system operates smoothly.

The constructed system needs to be continuously maintained so that it operates smoothly. The operation management system performs such maintenance and the like, and mainly manages three types of management such as network, system, and business operation.

For network and system management, failure countermeasures that detect hardware and software failures and recover by remote control, configuration management that manages hardware placement and free space on recording media, use of network traffic and processors There is performance management that manages rates, and security management that controls passwords and access rights. In business operation management, jobs are automatically executed according to a schedule, backups, and form output are executed.

As such an operation management system, for example, there is a workflow system that operates and manages a workflow, which is a sequence of one or a plurality of operations, as a system, and is applied to, for example, a process management system often found in manufacturing sites. ..

Patent Document 1 describes a development method called ticket-driven development in software development. In recent years, a development method called ticket-driven development has been used in software development sites. In the ticket-driven development, a Web-based ticket management system is used to generate information called “ticket” indicating each process of a project, and when the process is completed, the worker assigns the process to the ticket. It is a method of managing the process of a project by inputting the progress status indicating that it has finished. By writing the execution deadline of the process and the working time of the worker in this ticket, the ticket management system can manage the working time of the process.

JP, 2014-142885, A

However, in the ticket management system of Patent Document 1, the administrator pre-registers the order of the work performed by the worker from the Web browser. Therefore, the person in charge is fixed for each type of work. Also, one or more tickets are associated with one or more work orders. For this reason, if the order of the work becomes complicated, the worker will receive the mail related to the ticket many times, and the operation management system as a whole becomes complicated.

An object of the present invention is to provide a work automatic instruction system for monitoring the status of tickets.

In order to solve the above-mentioned problems, one of typical work automatic instruction systems of the present invention is a request registration system for registering a request related to a work from a customer, and the above-mentioned work depending on the skill of a person in charge. The ticket action system includes: a ticket action system that assigns a request to the person in charge and generates a ticket in which the order of the work is described; and a ticket workflow system that executes a workflow based on the ticket. The system has a monitoring unit that monitors the status of the ticket executed by the system based on the ticket.

According to the present invention, the ticket action system assigns a person in charge to the ticket regarding the work requested by the customer, and the monitoring unit of the ticket action system monitors the status of each stage of the ticket executed by the ticket workflow system. It becomes possible to do.

1 is an overall configuration diagram of a work automatic instruction system according to a first embodiment. FIG. 3 is a functional block diagram of the request registration system according to the first embodiment. FIG. 3 is a data configuration diagram stored in the request DB according to the first embodiment. FIG. 3 is a functional block diagram of the ticket action system according to the first embodiment. FIG. FIG. 3 is a data configuration diagram stored in a work list DB for each customer according to the first embodiment. FIG. 3 is a data configuration diagram stored in a skill DB of a person in charge according to the first embodiment. 3 is a data configuration diagram stored in a work order definition DB according to the first embodiment. FIG. 3 is a data configuration diagram stored in the ticket DB according to the first embodiment. FIG. FIG. 3 is a diagram for explaining a flowchart of the ticket workflow system according to the first embodiment and ticket status monitoring. FIG. 6 is a data configuration diagram stored in a request DB according to the second embodiment. FIG. 6 is a data configuration diagram stored in a work list DB according to the second embodiment. FIG. 6 is a data configuration diagram stored in a skill DB of a person in charge according to the second embodiment. 6 is a data configuration diagram stored in a work order definition DB according to the second embodiment. FIG. FIG. 6 is a data configuration diagram stored in a ticket DB according to the second embodiment.

Embodiments of the present invention will be described below with reference to the drawings.

(Constitution)
FIG. 1 is an overall configuration diagram of a work automatic instruction system according to the first embodiment. Here, a maintenance work is taken as an example of the work continuously performed by the operation management system for smoothly moving the constructed system, and the work automatic instruction system for automatically instructing this work will be described.

The work automatic instruction system includes a request registration system 100 that registers request information that is a request related to work from a customer, a ticket action system 300 that allocates a ticket related to work to a person in charge and monitors the status of the ticket, and a ticket action system 300. A ticket workflow system 400 that executes a workflow based on the ticket workflow system 400 is provided.

Each of the systems 100, 300, 400 is composed of a computer server device (hereinafter referred to as a server), and is connected via a network. A database used by each system (hereinafter, simply referred to as a DB, which is divided into a request DB 210, a work list DB 220, a skill DB 230, a work order definition DB 240, and a ticket DB 250) is also configured by a server and is connected via a network. ing. By recording a program for realizing processing by these system and each component in the DB in a computer-readable recording medium, and by causing the computer system to read and execute the program recorded in the recording medium. It is possible to execute various processes related to the work automatic instruction system.

FIG. 2 is a functional block diagram of the request registration system 100 according to the first embodiment. The request registration system 100 includes a receiving unit 110 that receives request information regarding work from a customer and a classifying unit 120 that classifies the received request information.

One or a plurality of customers inputs request information regarding work from the Web browser 10 in units of work.

The reception unit 110 receives request information input from the Web browser 10 in units of work. Here, it is assumed that the Web browser 10 is displayed and operated on the customer's terminal and is not included in the request registration system 100. Therefore, in FIG. 2, the web browser 10 and the information line from the web browser 10 to the receiving unit 110 are represented by a dashed line, while the request registration system 100 and the request DB 210 are represented by a solid line, and the request registration system 100 is a web browser. It is specified that 10 is not included.

The classifying unit 120 classifies the request information received in each work unit according to the customer name and the work date, and stores the classified request information in the request DB 210. Further, the classification unit 120 can read the information stored in the past from the request DB 210 and update it.

FIG. 3 is a data configuration diagram stored in the request DB according to the first embodiment. The request DB 210 is a table format database and is composed of a plurality of request records. The request record 215 surrounded by the one-dot chain line in FIG. "1" indicates that the customer name "customer 1" requests that the work name "X1, Y1, Z1" be the due date (from when to) "April 2017".

The request record 215 is a record in which the request information received for each work is classified into records according to the customer name and the work date. Next, how the request record 215 is updated and registered will be described.

For example, when the request registration system 100 receives the first request information from the customer 1 requesting the work name X1 from April 1, 2017 to April 30, 2017, the request DB 210 makes a request to the request DB 210. No. "1", customer name "customer 1", work name "X1", date "April 2017" are registered.

Next, when the request registration system 100 receives the second request information from the customer 1 requesting the work name Y1 from April 1, 2017 to April 30, 2017, from the request DB 210, Request No. The request information "1", customer name "customer 1", work name "X1", and date "April 2017" is read out, and the request number. "1" Customer name "Customer 1", work name "X1, Y1", date "April 2017" are updated and registered.

Finally, when the request registration system 100 receives the third request information from the customer 1 requesting the work name Z1 from April 1, 2017 to April 30, 2017, from the request DB 210, Request No. The request information "1", the customer name "customer 1", the work name "X1, Y1", and the due date "April 2017" are read out, and the request number. "1", customer name "customer 1", work name "X1, Y1, Z1", date "April 2017" are updated and registered. The request record 215 surrounded by the alternate long and short dash line in FIG. 3 shows the state of this update registration.

Note that, in FIG. 3, for convenience of description, the work name “X, Y, Z” is assigned the customer name “customer 1, customer 2, customer 3” and expressed as “X1” or the like. This "X1" means the work X requested by the customer 1.

FIG. 4 is a functional block diagram of the ticket action system according to the first embodiment. The ticket action system 300 includes a capturing unit 310 that captures a request record, an analyzing unit 320 that analyzes the request record, a generating unit 330 that generates a ticket, and a monitoring unit 340 that monitors the status of the ticket.

The acquisition unit 310 periodically reads the request DB 210 and acquires a new request record stored in the request DB 210. The timing of reading periodically may be once a day or the like.

The analysis unit 320 first analyzes the imported new request record using the work list DB 220.

FIG. 5 is a data configuration diagram stored in the work list DB for each customer according to the first embodiment. The work list DB 220 is a database in a table format, and the columns from the left are “customer name”, “work name”, “work content”, “remote support”, “work place”, “type”, “cycle”, and “cycle”. "Time zone" is described. Here, when the "type" is weekly or monthly, the work is a regular work. That is, FIG. 5 is a work list DB relating to regular work. The work list DB may include a work list regarding non-regular work.

The analysis unit 320 uses the work list DB 220 to analyze whether the work content of the request record is remote compatible “possible” or “impossible”. In addition, if the remote support is not possible, the work place is also analyzed. Furthermore, the columns of type, cycle, and time zone are also analyzed.

Next, the analysis unit 320 uses the skill DB 230 to analyze whether or not the person in charge has the skill of being in charge of the work.

FIG. 6 is a data configuration diagram stored in the skill DB of the person in charge according to the first embodiment. The skill DB 230 is a table format database, in which the vertical axis shows the work name and the horizontal axis shows the person in charge. For example, work “Y (tape cleaning)” is “A” and “B” are “OK” (that is, skill is available), but “C” is “No” (that is, no skill is available). Is listed.

Further, the analysis unit 320 analyzes the priority order among a plurality of works using the work order definition DB 240.

FIG. 7 is a data configuration diagram stored in the work order definition DB according to the first embodiment. The work order definition DB 240 is a database in a table format, and in order to describe the priority order among a plurality of works, “order” and “work name” are arranged from the left as columns. For example, when the work "X (server reboot)", "Y (tape cleaning)" and "Z (device patrol)" are performed, it is understood that the work needs to be performed in the order of X, Y, and Z.

In this way, the analysis unit 320 analyzes a plurality of request records using the work list DB 220, the skill DB 230, and the work order definition DB 240.

The generation unit 330 generates a ticket that assigns the work to the person in charge based on the analysis result of the plurality of request records performed by the analysis unit 320, and outputs the ticket to the ticket DB 250.

FIG. 8 is a data configuration diagram stored in the ticket DB according to the first embodiment. The ticket DB 250 is a tabular database, and from the left as columns, "ticket number", "person in charge", "ticket name", "work order", "work place", "type", "cycle", and "time". "Obi" are lined up. FIG. 8 illustrates a case where one ticket is assigned to one person in charge.

For example, with ticket number “1”, the person in charge “A” performs the work related to the three server reboots in the order of “X1→X2→X3” at the work place “3rd floor of the headquarters office” every Sunday from 18:00 to 20:20. It is described that it will be performed at 00:00. This work sequence “X1→X2→X3” corresponds to the workflow. Further, the work place is “the third floor of the head office” because it is possible to perform remote operation as shown in FIG. If remote support is not possible, the work location is written as, for example, "A center, 1st floor south". In this case, the person in charge moves to the work place "A center, 1st floor south" to perform physical work (tape cleaning, etc.).

It should be noted that a plurality of request information is not necessarily assigned to the ticket. For example, in the case of the ticket number “3”, only one request information (work name is Z1) received from the customer 1 may be assigned to the person in charge C. That is, the workflow may refer to one work sequence “Z1”.

The monitoring unit 340 reads the ticket from the ticket DB 250 and monitors the status of the ticket in the ticket workflow system 400 based on the read ticket.

(motion)
FIG. 9 is a diagram for explaining a flowchart of the ticket workflow system according to the first embodiment and ticket status monitoring.

The ticket workflow system 400 periodically reads the ticket from the ticket DB 250 and notifies the person in charge of the ticket (S410). The timing of reading periodically may be once a day or the like.

The process from S410 onward by the ticket workflow system 400 can be divided into a ticket preparation stage, an implementation stage, and a completion stage. The monitoring unit 340 of the ticket action system 300 monitors the status (state) of the ticket at each stage based on the ticket. Here, the ticket status includes, for each work constituting the work sequence, an alert (warning regarding a work instruction) indicating whether or not the time to perform the work is approaching, and completion of each work. Then, the monitoring unit 340 transmits the work instruction to the mobile terminal of the person in charge based on the work order described in the ticket.

For example, a case will be described in which the monitoring unit 340 reads the ticket with the ticket number “1” in FIG. 8 from the ticket DB 250 and the ticket workflow system 400 executes the ticket with the ticket number “1”. The ticket number “1” is the work sequence “X1→X2→X3” related to the regular work performed every Sunday, and when the work “X1” is completed, the status of the ticket number “1” is “X1 ends, Since X2 needs to be performed next, it is necessary to transmit a work instruction, and X3 is scheduled to transmit a work instruction after the end of X2."

In this way, the person in charge “A” can receive a work instruction from the monitoring unit 340 only for the work (here, X2) that needs to be performed next, and can handle a plurality of works (here, not only X2 but also X3). Regarding), the mail will not be repeatedly received (the X2 work instruction and the X3 work instruction at the same time).

In addition, since the ticket states "every week", only the work instructions for the week can be received from the monitoring unit 340, and it is not necessary to receive the work instructions for the next week and thereafter.

At the preparation stage, the ticket workflow system 400 also uses the skill DB 230 to examine whether the person in charge has the skill to perform the work assigned to the ticket (S420). If the person has the skill, the person in charge is approved (S430).

In the implementation stage, the follow-up requesting the person in charge to carry out the implementation is executed according to the “type”, “cycle”, and “time zone” (see FIG. 8) described in the ticket (S440). Then, the result executed by the person in charge is registered in the ticket (S450).

For example, when the result of the work "X1" performed by the person in charge "A" is registered (S450), it is necessary to follow the person "A" to perform the next work "X2" (S440).

Since the monitoring unit 340 monitors each status of the ticket based on the ticket DB 250, the monitoring unit 340 can automatically instruct the next work (in this case, the work “X2” by the person in charge “A”).

Next, when all the work described in the ticket is completed, the execution result is examined, and if there is no problem, approval is given (S460).

At the completion stage, the customer is notified that the work described in the ticket has been completed (S470).

(effect)
According to the work automatic instruction system of the present embodiment, the ticket action system 300 assigns the person in charge to the ticket regarding the work requested by the customer, and the monitoring unit 340 of the ticket action system 300 executes the ticket workflow system 400. It becomes possible to monitor the status of the ticket at each stage.

Further, the ticket action system 300 can automatically generate the work order performed by each person in charge as a ticket by using the work list DB 220, the skill DB 230, and the work order definition DB 240. Therefore, the administrator does not need to register the order of the work performed by the worker in advance.

Further, even if the work order performed by one person in charge becomes complicated, the ticket action system 300 monitors the ticket status for each work making up the work order, so that the worker does not receive an email regarding a plurality of works. It will not be received again, and the complexity of the operation management system as a whole can be eliminated. This is especially effective for regular work.

In the work automatic instruction system according to the second embodiment, the request registration system 100, the ticket action system 300, and the ticket workflow system 400 have the same configurations as those of the first embodiment, and thus the description thereof will be omitted. The feature of the second embodiment is that the number of records in each DB increases and one ticket is assigned to a plurality of persons in charge.

(Constitution)
Each DB according to the second embodiment will be described with reference to FIGS. 10 to 14. Here, each DB according to the second embodiment is the same as each DB described in the first embodiment in the functions and roles in the overall system configuration diagram of FIG. 1 and the functional block diagrams of the systems of FIGS. 2, 4, and 9. And the same symbols are used. However, when each DB according to the second embodiment is specifically represented in the table format, it is different from the table format of the first embodiment. Therefore, for convenience of description, in FIGS. 10 to 14 in which each DB according to the second embodiment is represented in the table format, “−2 (hyphen 2)” is added after the same reference numeral as in the first embodiment for distinction.

FIG. 10 is a data configuration diagram stored in the request DB according to the second embodiment. The description of the request record is the same as that shown in FIG. For example, the request No. of FIG. The request record of “1” indicates that the customer name “customer 1” requests the work name “server reboot” to be due (from when) to “May 2017”.

10 is different from FIG. 3 in that the classification unit of FIG. 2 classifies the request information received in the work units according to the work due date and stores the classified request information in the request DB 210-2. Therefore, the request No. for the customer name “customer 1”. Changes from "1" to "3", and the number of request records increases.

FIG. 11 is a data configuration diagram stored in the work list DB according to the second embodiment. The description of the record of the work list DB is basically the same as that of FIG. 5, and further, in the work list DB 220-2, a “work symbol” is added between the column “customer name” and the “work name”, and the column "Remarks" is added to the right of "Time Zone".

The column "work symbol" is a combination of letters and numbers. The letters represent work names and the numbers represent customer names. For example, when the work symbol is "WA1", the alphabetic character "WA" represents the work name "server reboot", and the number "1" represents the customer name "customer 1".

Note that the work symbols “WG3-1” and “WG3-2” are the same in that they are the customer name “Customer 3” and the work name “AD server system backup”, but the column “Remarks” is “every 2nd month”. "Tuesday" and "4th Tuesday of every month" are different. For this reason, "- (hyphen)" is followed by the number "1" or "2" so that they can be identified.

FIG. 12 is a data configuration diagram stored in the skill DB of the person in charge according to the second embodiment. Similar to FIG. 6, the vertical axis shows the work name and the horizontal axis shows the name of the person in charge. In the case of the second embodiment, since the work name is large, many work names are described in the skill DB 230-2.

FIG. 13 is a data configuration diagram stored in the work order definition DB according to the second embodiment. Similar to FIG. 7, the priority order among a plurality of works is described. In the case of the second embodiment, there are many work names, so many work names are described in the work order definition DB 240-2.

FIG. 14 is a data configuration diagram stored in the ticket DB according to the second embodiment. Different from FIG. 8, the ticket DB 250-2 has “ticket number”, “ticket name”, “person in charge”, “work order”, “work place”, and “remark” as columns from the left. FIG. 14 illustrates a case where one ticket is assigned to a plurality of persons in charge.

For example, in the ticket number “1”, two persons “A” and “B” are assigned to the ticket name “remote support”. The working place of the two persons in charge is “3rd floor of XX office”.

The person in charge “A” performs the work related to the remote operation in the order of “WA1→WC1→WG3-1→WG3-2→WJ4→WK4-3”. Further, the person in charge “B” performs the work related to the remote operation in the order of “WE2→WI4→WL5”.

Here, the column “Remarks” describes that “persons A and B execute according to the work order definition DB 240-2”. Therefore, the person in charge may perform the work that he/she should do after the other person performs the work.

For example, consider a case where the person in charge “A” performs “WG3-1” after work “WC1”. It can be seen from FIG. 11 that “WC1” is “AP activation confirmation”, and from FIG. 13 that the priority order is “3”. It can be seen from FIG. 11 that “WG3-1” is “AD server system backup”, and from FIG. 13 that the priority order is “7”.

On the other hand, the other person in charge “B” needs to perform the work “WE2”. It can be seen from FIG. 11 that “WE2” is “password change”, and from FIG. 13 that the priority order is “5”.

Therefore, when the person in charge “A” performs the work “WC1” and then “WG3-1”, the person in charge “A” finishes the work “WC1” and then the person in charge “B” performs the work “WE2”. After that, the person in charge “A” needs to perform the work “WG3-1”.

In such a case, according to the flowchart and status monitoring described in FIG. 9, first, the ticket number “1” is notified to the persons in charge “A” and “B” (S410). In the preparation stage, the persons “A” and “B” are examined (S420), and the persons “A” and “B” are approved.

Next, in the implementation stage, after the person in charge "A" finishes the work "WC1", the person in charge "B" is followed to perform the work "WE2" (S440). The work result is registered (S450). It should be noted that the examination approval of S460 is performed at the stage when the work for the entire ticket is completed.

Therefore, it is necessary to follow the person in charge "A" to perform the work "WG3-1" (S440) at the stage in which the result of the person "B" performing the work "WE2" is registered (S450).

Since the monitoring unit 340 monitors each status of the ticket based on the ticket DB 250, the monitoring unit 340 can automatically instruct the next work (in this case, the work “WG3-1” by the person in charge “A”).

(effect)
According to the work automatic instruction system of the present embodiment, the ticket action system 300 assigns a plurality of persons in charge to the ticket regarding the work requested by the customer, and further monitors the status of the ticket at each stage by the ticket workflow system 400. It becomes possible to do.

In addition, depending on the order of work, even when another person needs to perform another task after the work to be performed by one person is completed, a work order to be sent to the other person can be given. It becomes possible to carry out at an appropriate timing.

It should be noted that the present invention is not limited to the above-described embodiments, and includes various modifications other than maintenance work that can be applied to the operation management for smoothly operating the constructed system. For example, in the case of operation management work, it also includes the case where the status is monitored for each stage of preparation, execution, and completion of a ticket that describes the execution deadline of each process of the operation management project and the work time of the worker in charge. The above-described embodiments have been described in detail for the purpose of explaining the present invention in an easy-to-understand manner, and are not necessarily limited to those having all the configurations described. Further, a part of the configuration of a certain embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of a certain embodiment. Further, it is possible to add/delete/replace other configurations with respect to a part of the configurations of the respective embodiments.

Further, each of the above-described configurations may be partially or entirely configured by hardware such as by designing with an integrated circuit, or configured by being executed by a program by a processor. Good. Further, the control lines and information lines are shown as being considered necessary for explanation, and not all the control lines and information lines in the product are necessarily shown. In practice, it may be considered that almost all configurations are connected to each other.

100 request registration system 210, 210-2 request DB
215 request record 220, 220-2 work list DB
230, 230-2 skill DB
240, 240-2 Work order definition DB
250, 250-2 Ticket DB
300 Ticket Action System 310 Importing Part 320 Analyzing Part 330 Generating Part 340 Monitoring Part 400 Ticket Workflow System

Claims (8)

A request registration system that registers requests for work from customers,
A ticket action system that assigns the request to the person in charge according to the skill of the person in charge of the work and generates a ticket in which the order of the work is described;
A ticket workflow system for executing a workflow based on the ticket,
The ticket action system is a work automatic instruction system having a monitoring unit that monitors the status of the ticket executed by the ticket workflow system based on the ticket. The ticket workflow system is
A work list database that describes at least whether the work can be handled remotely,
A skill database that describes whether the person in charge has the skills to perform the work,
An analysis unit that analyzes the request using the work list database and the skill database,
A generation unit that allocates the request to the person in charge based on an analysis result by the analysis unit and generates a ticket in which the order of the work is described,
The work automatic instruction system according to claim 1, wherein the ticket describes whether remote correspondence is possible or whether it is necessary to move to a work place. The ticket workflow system further comprises
It has a work order definition database that describes the priority order among the works,
When there are a plurality of works, the analysis unit analyzes the priority order among the plurality of works using the work order definition database, and the monitoring unit displays a ticket in which the order of the plurality of works is described. The work automatic instruction system according to claim 2, which is generated. 4. The work automatic instruction system according to claim 3, wherein the monitoring unit monitors the status of the ticket for each of the works constituting the order of the plurality of works and sends a work instruction to the person in charge. When the ticket is assigned to a plurality of persons in charge, the monitoring unit issues a work instruction to another person in charge according to the order of the plurality of tasks, after the task to be performed by one person is completed. The work automatic instruction system according to claim 4, which transmits. The analysis unit uses the work list database to analyze whether the request is related to regular work,
The work automatic instruction system according to claim 2, wherein the ticket describes whether or not the work is a regular work. A work automatic instruction method for automatically instructing work according to a request regarding work from a customer,
Register the work request from the customer,
Assigning the request to the person in charge according to the skill of the person in charge of the work, generating a ticket in which the order of the work is described,
A work automatic instruction method for executing a workflow based on the ticket and monitoring the status of the executed ticket based on the ticket. A program for causing a computer to execute a system for automatically instructing work in response to a request regarding work from a customer,
Registering a request for work from the customer,
Assigning the request to the person in charge according to the skill of the person in charge of the work, and generating a ticket in which the order of the work is described;
Executing a workflow based on the ticket,
And a step of monitoring the status of the ticket to be executed based on the ticket, the work automatic instruction program.

Images