JP2000353113A - Fault management system and method, fault management device and recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make it possible to easily execute the change or the like of a workflow program in a fault management system realized by a client-server system. SOLUTION: Each of a client 10 and a server 20 is provided with at least a data I/O function utilizing a web or mail function and the server 20 is provided also with a workflow state transition processing part 26 for executing workflow processing on the basis of fault management operation data sent from the client 10. The workflow processing for fault management is executed only in accordance with a program stored in the server 20 and data transmission/reception to/from the client 10 which is required for executing the fault management operation is executed simply by using the web or mail function, so that the client 10 can sufficiently deal with the workflow processing only by the normal web or mail function even when the client 10 is not provided with the program for the workflow processing.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a fault management system and method, a fault management apparatus, and a recording medium storing a program for realizing these functions.
Software (programs) running on computers
This is suitable for use in a system for managing a failure that occurs in a computer.

[0002]

2. Description of the Related Art In software fault management in system development, work efficiency is improved when a bug (failure) in a program is found and debugged, or a mistake in a document is corrected. It is necessary to manage information necessary for debugging and the like, manage work, and the like in order to achieve appropriateness. Therefore, it is required that a failure management system incorporates such functions as information management and work management.

That is, the fault management system not only compiles a program under development or that has been developed and simply accumulates the obtained error information so that it can be referred to, but also has fault management information for the error. It is necessary to provide a function to monitor and manage whether appropriate measures are taken, and a function to manage the points indicated by the results of reviewing documents. In the conventional fault management system, the above-described functions are realized by using a so-called workflow system that shares information related to office work between departments and manages the flow of the information.

For example, there is a system in which the above-described workflow program is incorporated in a client-server system to manage error information and manage countermeasures. In this case, when information on a failure found in the created software is registered on the client side, the fact is transmitted to the server side, and the measures against the failure are managed on the server side in the form of a workflow. Then, according to the workflow, a countermeasure instruction is issued to the software development department, and when the countermeasure is completed in response thereto, the fact is notified to the approval department. Here, when the measure is approved, the result of the measure is notified to the client side.

In such a client-server system, a workflow system can appropriately manage software fault information and countermeasure work. Usually, the program of the workflow system is not only installed on the server side, but also a part of the program is installed on the client side, and functions as the entire system.

[0006]

However, in a conventional fault management system realized on such a client-server system, a workflow program is constructed in advance by assuming the flow of fault information and appropriate countermeasure work. In. For this reason, if you try to change the workflow of failure management, such as performing a series of troubleshooting measures on a different route from the past, or performing troubleshooting on a different route for software customized for each project , The workflow program itself must be updated.

At this time, the conventional fault management system is a system in which the workflow program on the server side and the workflow program on the client side function integrally, so that the updating of the workflow program is performed not only on the server side but also on the server side. You have to do it for each individual client. Therefore, there is a problem in that the updating work and management are very complicated, and much labor and time are required.

When a fault management system is constructed via a large network such as a WAN (Wide Area Network), a so-called gateway device for interconnecting systems of different protocols must be provided. However, there is a problem that the program of the gateway device must be updated according to the workflow, and the consistency between the client and the server must be adjusted.

There is also a case where it is desired to change the role of a user who works on the client side, defined in the workflow, without changing the fault management workflow itself. In this case, it is necessary to perform management such as correcting and adding a program on the client side related thereto, but this operation is also very complicated, and there is a problem that much labor and time are required.

Furthermore, in the conventional fault management system, the client side must also have a workflow program, so that the client side memory is used accordingly. For this reason, a large amount of client-side system resources are used, and the available memory area is compressed. If a lot of system resources are used in this way, it becomes impossible to start applications other than the fault management system on the client side,
Even if it can be started, it does not work well, and there is a problem that it may hinder the normal work of the user.

Further, the conventional fault management system is realized by a workflow program such as groupware, and is permitted to be used only by a client that has installed the groupware program. However, recently, software development is often distributed among a plurality of organizations, a plurality of projects, or a plurality of companies, and there is a demand for external participation in one workflow system. Many are occurring.

Therefore, the mechanism of the conventional fault management system that permits only a specific client to participate in a workflow is not suitable for the current situation.
In this case, in order for a user other than a predetermined client to newly participate in the workflow, it is necessary to install a groupware workflow program on the client and perform necessary settings, and the work is very often performed. There is a problem that requires much labor and time.

The present invention has been made in order to solve such a problem, and has a simple configuration of a fault management system realized by a client server system.
A first object is to facilitate maintenance such as a change of a workflow program. It is a second object of the present invention to save the use of system resources on the client side and reduce the load on the resources used on the client side.

Further, a third object of the present invention is to improve the efficiency of work for failure management in accordance with the first and second objects. Further, the present invention enables a required client user to easily participate in a workflow of failure management when performing distributed development of software, and can improve security, which is an important issue at that time. Is the fourth object.

[0015]

The fault management system according to the present invention comprises a client server system.
A failure management system for managing a failure occurring on software in accordance with a workflow, wherein the client and the server have at least a data communication function, and the server further includes a failure management system based on the failure management operation data sent from the client. A workflow processing means for performing the workflow processing, wherein the workflow processing is performed only in the server, and various notifications between the client and the server accompanying the workflow are performed by the data input / output function. Features.

For example, the client and the server have at least a data input / output function by a web (WEB), and the server further has a web (WEB) of the client.
EB) a workflow processing means for performing the workflow processing based on the failure management business data input and transmitted by the function. Further, the client and the server have at least a data input / output function by e-mail, and the server further includes an ID assigning means for assigning an ID unique to the failure that has occurred, and failure management business data transmitted by the e-mail function of the client. There may be provided a workflow processing means for detecting correspondence with a failure based on the ID included therein and performing the workflow processing based on the failure management work data. In this case, the ID may be included in the header of the mail.

In another aspect of the present invention, the server comprises: a failure information management unit for storing and managing the failure management business data sent from the client; List processing means for creating a list of faults that have occurred using the management task data and transmitting the list to the client, wherein the client displays a list of faults created and sent by the list processing means It is characterized by further comprising a list display means.

In another aspect of the present invention, the server uses the fault management business data stored and managed by the fault information management means to execute the next operation from the current state with respect to the fault being handled. It further comprises a work information processing means for creating list information and sending it to the client,
The client may further include a work list display unit that displays the work list information created and transmitted by the work information processing unit.

The fault management method according to the present invention is a fault management method for managing faults occurring on software in accordance with a workflow, wherein a client of a client-server system detects a fault occurring on the software by a server. A first step of registering with the side,
A second step of outputting a fault management task instruction to an appropriate client according to the workflow in accordance with the registered fault in the server, and inputting fault management task data relating to the task performed in the client; A third step of outputting to the server; and a fourth step of performing, in the server, the workflow on the basis of the failure management work data input from the client. After the registration, the processes of the second to fourth steps are repeatedly performed.

Here, the exchange between the client and the server may be performed by a web input / output function. In addition, the method further includes, after the first step, a step of assigning a unique ID to the registered fault in the server, and performing an exchange between the client and the server using a mail including the ID. It may be performed by a function. Further, the instruction in the second step is performed by e-mail, the failure management work data in the third step is input by a web function,
The workflow processing in the fourth step may be performed based on the fault management work data input by the web function.

Further, the fault management apparatus of the present invention is a fault management apparatus for managing faults occurring on software in a server configured by a client-server system in accordance with a workflow, and is sent from a client. Workflow processing means for performing the processing of the workflow based on the fault management work data and notifying a predetermined client to the client defined by the workflow.

According to another aspect of the present invention, a failure information management means for storing and managing the failure management business data sent from the client, and a failure management business data stored and managed by the failure information management means are provided. And a list processing means for creating and transmitting a list of faults that have occurred.

According to another aspect of the present invention, a work that can be performed next from the current state according to a predetermined workflow with respect to a fault that is being handled, using the fault management business data stored and managed by the fault information management means. And a work information processing means for creating and transmitting the list information.

Further, a computer-readable recording medium according to the present invention is characterized in that a program for causing a computer to function as each means according to any one of claims 1 to 7 and 13 to 18 is recorded. I do. According to another aspect of the present invention, a program for causing a computer to execute the processing procedure of the fault management method according to any one of claims 8 to 12 is recorded.

In another aspect of the fault management system according to the present invention, the fault management system comprises a client-server system for managing faults occurring on software in accordance with a workflow. And a data input / output function by at least one of mail and the server, further comprising: a workflow processing means for performing the workflow processing based on the fault management business data input and transmitted by the data input / output function of the client. An authentication unit for performing user authentication using user information sent from the client and user information registered in the server in advance, performing the workflow process only in the server, Accompanying client service Various notifications between with to perform the above data input and output functions, characterized in that so as to allow participation in the process of the workflow to a user that the user authentication has been performed.

In another aspect of the present invention, the workflow processing means executes processing of a plurality of different workflows, and the user authentication means performs the user authentication for each of the plurality of different workflows. Features. Another aspect of the present invention is characterized in that a switching unit that switches ON / OFF of the user authentication function by the user authentication unit is provided.

Another aspect of the fault management method according to the present invention is a fault management method for managing faults occurring on software according to a workflow, wherein a client of a client-server system generates a fault on the software. A first step of registering the fault that has occurred in the server, a second step of outputting, in the server, a fault management operation instruction to an appropriate client in accordance with the workflow in accordance with the registered fault, Third, the failure management business data relating to the performed business is input and output to the server.
And a fourth step of performing, in the server, the workflow based on the failure management business data input from the client, after the failure is registered in the first step, the fourth step is performed. The processing of the second step to the fourth step is repeatedly performed, and the processing of the first and third steps is performed at an arbitrary stage by the user information input in the client and the user registered in the server in advance. The process is performed by a user who has received the user authentication based on the information and participated in the process of the workflow.

Another aspect of the present invention is characterized in that processing of a plurality of different workflows is executed in the same system, and the user authentication is performed for each of the plurality of different workflows. According to another aspect of the present invention, the user authentication function can be switched ON / OFF, and the user authentication is executed only when the function is turned ON.

According to another aspect of the fault management apparatus of the present invention, a fault management apparatus for managing faults occurring on software in a server configured by a client-server system in accordance with a workflow, comprising: Based on the failure management business data sent from the workflow processing means, performs the above-described workflow processing, performs a predetermined notification to the client defined in the workflow, user information sent from the client An authentication unit for performing user authentication using user information registered in the server in advance.

In another aspect of the present invention, the workflow processing means executes processing of a plurality of different workflows, and the user authentication means performs the user authentication for each of the plurality of different workflows. Features. Another aspect of the present invention is characterized in that a switching unit that switches ON / OFF of the user authentication function by the user authentication unit is provided.

According to another aspect of the present invention, there is provided a computer-readable recording medium.
A program for causing a computer to function as each of the means described in any one of Items 7 to 29 is recorded. In another aspect of the present invention, claims 24 to 26 are provided.
A program for causing a computer to execute the processing procedure of the fault management method according to any one of the above items is recorded.

Since the present invention comprises the above technical means, the workflow processing for fault management is performed only according to the program in the server, and the data exchange with the client required for performing the fault management work according to the workflow is performed. This is performed simply using the web function or the mail function. Thus, the client does not need to have a program for workflow processing, but only needs to have a program for a normal web function or mail function.

According to another feature of the present invention, a list of faults that have occurred is created, and the list is sent to the client for display. It can be seen as a list, for example, to what state the workflow has progressed for each of those failures.

According to another feature of the present invention, with respect to a fault being handled, list information of work that can be performed next from the current state is created, and the list information is transmitted to the client and displayed. In addition, the user can easily grasp in advance the contents of work to be performed next in a series of workflows for troubleshooting.

According to another feature of the present invention, when data is exchanged between a client and a server by e-mail, an ID required to cope with a failure is provided by an e-mail which is not directly visible to the user. Of the client, the client user can perform the fault management work simply by exchanging necessary mails without being conscious of the ID.

According to another feature of the present invention, user authentication is performed using user information sent from the client and user information registered in the server in advance.
Since the user who has been authenticated is allowed to participate in workflow processing, it is not necessary to configure the fault management system with groupware, and it is necessary when distributed development of software is performed. Such a user will be able to participate in the workflow once it is authenticated.

According to another feature of the present invention, when a plurality of different workflows are processed in one fault management system, user authentication is performed for each of a plurality of different workflows. In addition, it is possible to allow participation only in a specific workflow among a plurality of workflows operating in the system.

According to another feature of the present invention, the user authentication function can be switched ON / OFF. By turning off the user authentication function, a user name and a password such as a user name and a password can be set when logging in. It is possible to save the trouble of inputting information.

[0039]

DESCRIPTION OF THE PREFERRED EMBODIMENTS One embodiment of the present invention will be described below with reference to the drawings. (First Embodiment) FIGS. 1 and 2 are block diagrams showing a configuration example of a fault management system according to the present embodiment.
FIG. 1 shows a detailed functional configuration in the system, and FIG. 2 shows a schematic configuration of the entire system.

As shown in FIG. 2, in the fault management system according to the present embodiment, a plurality of client machines (hereinafter, abbreviated as clients) 10, 10,... It is configured as a client / server system connected via the PC 40. Further, a terminal 30 for an administrator who manages the failure management system is connected to the server 20. Further, the server 20 includes a database 21 for storing fault management business data including information on a transition state of a workflow described later. In addition, this database 21
It may be file-based. For example, it is a text file simply stored as one or a plurality of files.

As shown in FIG. 1, the client 10 is a user terminal equipped with ordinary mail software having functions such as a mail transmission unit 11, a mail reception unit 12, a mail reply unit 13, and a file attachment unit 14. . This client 10 is used by various users belonging to a development department of application software and a department using the application software.

As will be apparent from the following description, the client 10 of the present embodiment only needs to have the above-mentioned general-purpose mail-based program when performing software fault management. It is not necessary to provide a workflow program for the purpose. On the other hand, the server 20 includes an e-mail program for transmitting e-mail to the client 10, receiving e-mail from the client 10, and performing a corresponding process, and a workflow program for failure management. That is,
In the present embodiment, only the server 20 has a workflow program for failure management.

The administrator terminal 30 includes an input form definition unit 31 and a workflow definition unit 32. The input form definition unit 31 defines several types of input forms (various forms such as a failure registration form and a failure countermeasure report form) of a report submitted by a user when performing software failure management. Here, a template that lists necessary items to be input in a report sent as an e-mail is defined for each operation stage (workflow transition state) performed in response to a failure.

In addition, the workflow definition unit 32 distributes information related to the failure management work between the application development department and the use department, and how to take measures against the failure in what procedure. Is to define a workflow that represents. Further, each client 10
It also defines the role of the user who uses the service (eg, the person in charge of taking measures against failures, the administrator who supervises multiple persons in the department), and the process of defining the email notification range for each input form. Do with.

FIG. 3 is a flowchart showing a procedure when the input form definition unit 31 and the workflow definition unit 32 define an input form and a workflow model. In FIG. 3, first, in step S1, information such as who is in which department as a user participating in the fault management system and what the roles of those users are are defined. Normally, one role is defined for one person. However, it is also possible to define a plurality of roles for one person, such as the above-mentioned person in charge and the manager.

Next, in step S2, a workflow for failure management is defined. Here, for example, which type of failure registration report is received, which department should be notified of it, the flow of failure management information that says to notify the user when a failure countermeasure completion report is received, In the state of a certain workflow, a work procedure or the like as to what kind of work to be performed as a person in charge or a manager is defined.

Further, in step S3, after defining various input form templates by the input form definition unit 31, in step S4, the notification range of the mail created based on the various input forms, that is, who in which department, Is defined for each email message. When the various definitions are completed as described above, the contents of those definitions are stored in a file in step S5. FIG.
As shown in, input form 3 defined in this way
3. The file of the workflow model 34 is stored in the server 20
Given to and saved.

FIG. 4 is a flowchart showing a procedure for defining a template of an input form in step S3 of FIG. In FIG. 4, first, step S
At 11, the items necessary for a certain input form are listed. For example, items necessary for the fault registration form include items such as a fault name, a fault occurrence target environment, a symptom, a measure deadline, and a degree of importance. In addition, the items required for the failure countermeasure report form include items such as a failure name, a cause of the failure, details of the countermeasure, a version number of the corrected program, and a man-hour for correction.

Next, in step S12, the above step S
After determining the data input format (data type, number of characters, etc.) for each item listed in step 11,
At 3, it is determined whether or not data input to each item can be omitted. Here, for items for which it is determined that data input cannot be omitted, a check is made when actually sending an e-mail, and if no data has been input, an error message will be output. Such a function of checking required input items is performed on the server 20 side. Note that the processing may be performed on the client 10 side using JAVA or the like.

In the next step S14, it is determined whether or not the input form is completed. If the input form is not completed due to omission of definition of the item, the process returns to step S11 to perform the same processing. On the other hand, when the input form is completed, the process proceeds to step S15, and the input form is stored in a file. By performing the processing of steps S11 to S15 as described above for various input forms, various input form files are generated.

Next, a specific configuration in the server 20 will be described with reference to FIG. As described above, the server 20 of the present embodiment has a workflow management function and a mail management function, and the latter mail management function is realized by the mail server 22. The mail server 22 receives various emails sent from the client 10, passes them to the workflow management means described below, and performs processing such as transmitting the emails generated by the workflow management means to the client 10. The workflow management unit is configured by functional blocks other than the mail server 22 and the information list processing unit 28 in the server 20 shown in FIG.

The submitter check unit 23 checks the input form 3
When a request for acquisition of a request, a request for displaying a list of failures, or a report created based on a certain input form is sent from the client 10 by e-mail, the submitter has a role to send the e-mail. Check if you are. This can be done by referring to the information of the sender contained in the header of the mail and the role of each user defined in the workflow model 34.

The workflow state determination unit 24 determines what the current state is in the failure management workflow for each failure that has occurred, based on the definition information of the workflow model 34 and a report or the like given from the client 10. Things. For example, it is determined which state is currently in the initial state in which the failure has just been registered, during the investigation of the cause of the failure, during the countermeasure for the failure, the countermeasure is pending, and the countermeasure is completed. At this time, of the plurality of registered failures, which failure the given report is for is specified by an ID described later included in the header part of the mail.

The identification number assigning section 25 assigns a unique identification number (ID) to a fault in an initial state in which fault registration has just been performed. At this time, database 2
The identification number assigned to the various failure management work data (reports and the like) already stored in the storage device 1 is added, and the number next to the largest number is assigned as an ID for a new failure.

The workflow state transition processing unit 26 executes a process of transitioning the state of the workflow every time a process is performed by a person in charge of failure or an administrator and a report thereof is notified by e-mail. This is done by reading information representing the transition state of the workflow stored in the database 21 and defining the defined workflow model 34.
Is performed according to the content of the report sent from the client 10 by e-mail. The information of the transition state updated in this way is
It is stored again in the database 21 together with the given report.

The workflow state transition processing unit 2
6 also performs a process of notifying an appropriate client 10 defined in the workflow according to the defined workflow model 34 of the next task instruction.
This work instruction may indicate the work to be performed next by transferring the report given from one client to another client as it is,
A clear work instruction may be created and sent. This notification is performed in a mail format via the mail server 22.

The state transition notifying section 27 defines, when the state of the workflow relating to a certain failure is changed by the workflow state transition processing section 26, such a state change within the notification range. This is to notify the client 10 of the current user. This notification is also made in the form of mail via the mail server 22. The work instruction and the notification of the state transition may be made together.

The information list processing unit 28 creates a list of information on various failures stored in the database 21 when a request is made by e-mail from the client 10, and sends the list to the client via the mail server 22. 10 is performed. The information of the failure list may be sent in the form of being incorporated in the mail, or may be sent as an attached file to the mail. The information of the failure list includes the failure number (I
D), information such as the current state of the workflow and the name of the failure.

The operation of the fault management system according to the present embodiment configured as described above when a fault occurs will now be described with reference to the flowcharts of FIGS. 5 shows an operation when the client 10 obtains the template of the input form 33 stored in the server 20. FIG. 6 shows a report created based on the input form 33 sent from the client 10 to the server 20 by mail. FIG. 7 shows the operation when submitting in FIG.
Shows the operation of the main processing shown in FIG.

First, when any trouble (bug) is found, for example, when the created application is used on a certain client 10 or a user terminal (not shown), the user reports the found trouble. In order to obtain the fault registration form to be used at that time from the input form 33 of the server 20, the user who has found the fault needs to use the mail transmitting unit 1 of the client 10 used by the user.
A request for obtaining the form is sent from server 1 to server 2 in the form of e-mail.
Send to 0.

When the mail server 22 in the server 20 receives the form acquisition request mail in step S21 of FIG. 5, the submitter check unit 23 in step S22
The workflow model 34 is read. Then, in the next step S23, the read workflow model 34 is read.
With reference to the role definition information of the user defined in and the user name described in the header part of the received mail, whether the request of the failure registration form has been issued from the correct submitter, that is, Then, it is determined whether or not the submitter has a role that can perform the fault registration.

If the request is from the correct submitter, the process proceeds to step S24, and it is determined whether the requested form exists. Since the fault registration form requested here exists, the process proceeds to step S25, and the template of the fault registration form is transmitted to the requesting client 10 via the mail server 22. This transmission is performed in a form attached to a reply mail to the form request, and the mail is received by the mail receiving unit 12 in the client 10 that has made the request.

In step S23, when it is determined that the request for the fault registration form is not made by the correct submitter, and in step S2
If it is determined in step 4 that the requested form is not stored as the input form 33 in the server 20, the process proceeds to step S 26, and an error notification is sent to the form requesting client 10 via the mail server 22. Done.

When the client 10 receives the trouble registration form, the user creates a trouble report by describing necessary items in each item in the form, and sends the trouble report from the mail transmission unit 11 or the mail reply unit 13 to the server. 20. At this time, the failure report is attached to the mail by the file attachment unit 14 and transmitted. In step S31 in FIG. 6, the mail server 2 in the server 20
When 2 receives the trouble report mail, the workflow processing described below is executed.

That is, the submitter check unit 23 reads the workflow model 34 in step S32, and in step S33, reads the workflow model 34
Refers to the role definition information of the user defined in the above and the user name described in the header of the received mail to determine whether or not the submission of the trouble report is performed by the correct submitter. I do.

If the submitter is a correct submitter, the process proceeds to step S34 to execute the main process shown in FIG. On the other hand, if the submitter is not the correct submitter, the process proceeds to step S35, and an error notification is sent via the mail server 22 to the client 10 that submitted the failure report.

In the main process shown in FIG. 7, first, in step S41, the workflow status determination unit 24 determines whether the report received by e-mail from the client 10 is the first report on the failure, that is, the workflow status on the failure. It is determined whether or not has already progressed. Here, the first report on a certain failure is a failure report when the occurred failure is first registered. Therefore, if it is determined whether the received report is a failure report, it is possible to determine at least whether the failure currently targeted is in the initial state.

If the received report is the first report on the fault, the identification number numbering unit 25 reads the fault information already stored in the database 21 in step S42, and reads the fault information in the next step S43. A unique ID is assigned to the new fault reported this time by incrementing the already assigned identification number (ID) to the fault information. In this example, since the server 20 has received the failure report, a number is assigned to the failure in steps S42 and S43. The numbered report information is stored in the database 21.

Next, the process proceeds to step S44, where the workflow state transition processing unit 26 reads information on the failure currently being processed by the workflow from the database 21, and transitions to the next state in step S45. For example, when a failure report has just been registered, the state of the workflow is changed from the initial state before the occurrence of the failure to the state under investigation.

Then, in step S46, the workflow state transition processing unit 26 sends a message to the client 10 of an appropriate user (in this example, a person who should take measures against a failure) defined in the workflow model 34. The next fault management work instruction is notified by e-mail. At this time, an ID unique to the failure is included in the header of the mail. In this step S46, the state transition notifying unit 27 also performs a process of notifying the client 10 of the user defined in the notification range of information on the state transition of the workflow.

FIG. 8 is a diagram showing a screen display example of a failure report notified as a failure management operation instruction. In this screen display, [Fault Report] is displayed as "Subject" on the top line, and bibliographic information such as the source, destination, and date of the mail is displayed over several lines from the next line Have been. Below that, the trouble number (ID) and name,
The submitter, report name, and state transition are displayed, so that you can see at a glance what obstacle is currently in what state in the workflow.

Further below, the submitter (discoverer of the fault)
Displays the specific contents of the failure report described based on the input form 33. The items shown in black and white brackets in the screen of FIG. 8 are items presented as a template of the fault registration form. When the form is obtained, only the item names are displayed, and the contents are blank. The figure shows the state after the failure finder has completed the failure report by filling in each of these items.

The person in charge (system developer) who has received such a failure report mail takes necessary measures to eliminate the reported failure. For example, the program is modified as needed. If a countermeasure is taken, the fact is described as a countermeasure report and transmitted to the server 20 by e-mail. At this time, the person in charge first obtains the failure countermeasure report form from the input form 33 of the server 20. Then, a necessary measure report is created by describing necessary items in each item in the obtained fault measure report form, and the report is transmitted by e-mail. The ID is also included in the header part of this mail.

When obtaining the fault countermeasure report form,
As in the case of obtaining the fault registration form, a process of determining whether or not the form request has been issued from the correct submitter is performed. Further, when the server 20 receives the mail of the countermeasure report created based on the form, the server reads the ID written in the header of the mail and associates the ID with the failure report. And relying on that ID,
In the same manner as when the failure report mail is received, the current state of the workflow is determined and a process of transitioning to the next state is performed (in the case of the present example, the state transitions from during cause investigation to countermeasure).

Further, the server 20 detects to which user the received countermeasure report is to be sent next according to the workflow model 34, and transmits it to the client 10 of an appropriate user (for example, an administrator). The user of the client 10 receiving this determines whether there is a problem in the report of the countermeasure report, and if there is a problem, gives an instruction to return the correspondence by e-mail. On the other hand, if there is no problem with the report, send an email of the completion report,
The state of the workflow is changed to "measures completed".

Here, an example is shown in which the person in charge of receiving the failure report immediately takes necessary measures. However, the cause of the failure is reexamined, and opinions on the failure are exchanged with other persons in charge. Or temporarily suspending countermeasures due to the occurrence of another emergency that requires urgency. In such a case as well, input forms corresponding to those aspects are obtained from the server 20 to the client 10, and a report prepared by describing necessary items is returned to the server 20 by e-mail. The server 20 transitions the state of the workflow in accordance with the sent report, and notifies the appropriate user of the report according to the workflow.

When a list display request is sent from the client 10 of a certain user to the server 20 by e-mail, the server 20 first checks whether or not the user is a correct submitter by the submitter check unit 23. If the request for displaying the list is issued from the correct submitter, an instruction to create a list is issued to the information list processing unit 28, and report information on each fault is extracted from the database 21 to generate a list. Then, the list information is incorporated into the mail as an attached file and transmitted to the client 10 via the mail server 22.

As described in detail above, in the fault management system of the present embodiment, the client 10 and the server 20
Is exchanged by e-mail with failure ID,
All the workflow processes of the fault management are sequentially executed only in the server 20 based on the fault ID. Therefore, at least the client 10 does not need to have a program for a workflow, and only needs to have a normal mail program. As a result, even when the workflow of the fault management is changed, only the program on the server 20 is updated, and the program on the individual client 10 side does not need to be updated. And management becomes very easy.

Further, the fault management system of the present embodiment
Even when the system is constructed via a large network such as an AN (Wide Area Network), it is not necessary to modify a program of a gateway device for interconnecting systems of different protocols. Further, even when the role of the user who performs the work is changed on the client side, the program on the client 10 side does not need to be modified at all. As described above, according to the present embodiment, the labor and time required for maintenance of the fault management system can be significantly reduced.

As described above, the client 10 only needs to have ordinary mail software. However, in the mail, in order to deal with each fault in the workflow process on the server 20 side, a fault specific mail is used. And an email is created based on a predetermined input form 33. However, this ID is given in the flow of the workflow processing on the server 20 side, and is written in a hidden part such as the header part of the mail. Therefore, since the user of the client 10 only needs to fill in and send the determined items in the input form 33 without being conscious of the ID at all, there is a merit that the work is easy.

In this embodiment, the client 10
Since it is not necessary for the client 10 to have a workflow program at all, the use of memory on the client 10 side can be saved. As a result, more system resources on the client 10 side can be released than before, and it becomes impossible to start an application other than the fault management system on the client 10 side, and even if it can be started, it does not operate well. Inconveniences such as inconvenience can be avoided.

Further, in the present embodiment, a list of information relating to various faults is created by the information list processing unit 28 in response to a request given from the client 10 at an arbitrary time, and the list is sent to the client 10 in the form of mail. I try to send. This list display only looks at the current workflow state from the report information of each failure stored in the database 21. In other words, without actually moving the workflow, it is possible to view a list of various failure states at a certain point in time obtained as a result of moving the workflow.

As a result, the user can view a list of the currently occurring failures in the target application software and the progress of the workflow for each of those failures. It can be an effective reference when performing maintenance work on the created application.

(Second Embodiment) Next, a second embodiment of the present invention will be described. In the first embodiment, communication between the client 10 and the server 20 is performed on a mail basis even when a list of information on various failures is displayed. On the other hand, the second embodiment converts this into HTML
It is a web-based format.

FIG. 9 is a block diagram showing a functional configuration of the fault management system according to the second embodiment. In the second embodiment, the client 10 has ordinary browser software in addition to the ordinary mail software described above, and includes an information list display unit 15 as one of the functions.

On the other hand, the information list processing unit 29 in the server 20
Creates a web-based list of various failure information stored in the database 21 and sends it to the information list display unit 15 in the client 10 when there is a request from the client 10 by e-mail. The information list processing unit 29 also uses the fault management business data stored in the database 21 to create list information of work that can be performed next from the current state with respect to the fault being handled, and transmit the list information to the client 10. Also do.

The other functional blocks shown in FIG. 9 have the same functions as those shown in FIG.
They are given the same reference numerals in both figures.

FIG. 10 is a view showing an example of a failure list displayed on the information list display section 15 on a screen. As shown in FIG. 10, a list of faults currently being handled is displayed in the top frame of the screen. The information of the failure list includes information on the failure number (ID), the last update date, the current state of the workflow, and the failure name. An anchor (underline) is drawn below the failure number, and clicking on it with the mouse displays detailed information on the current state of the workflow regarding the failure in the lower frame.

The example of FIG. 10 shows a display example when the location where the fault number is 15 is clicked. The workflow status frame contains historical information on what work has been done and by whom about the failure, and what role the user has from the current state, and what kind of report. Work list information indicating what can be submitted, that is, what work can be performed next. In the present embodiment, since one person can have a plurality of roles, a task that can be performed next as a manager and a task that can be performed next as a person in charge are presented.

For example, as a manager, if a countermeasure completion report is submitted from the “under countermeasure” state, the state can be changed to the “countermeasure completed” state. In addition, as a person in charge, submit a countermeasure report or opinion report from the "Measures in progress" status to maintain the "Measures pending" status, or submit a countermeasures pending report to transition to the "Measures pending" status. Or submit a re-investigation report to “under investigation”
Or the state can be changed.

In the first embodiment shown in FIG. 1, a user of a certain role creates a report and sends it to the server 2 by e-mail.
When it is sent to 0, the submitter check unit 23 checks the submitter and outputs an error if the submitter is not the correct submitter. On the contrary,
According to the present embodiment, it is possible to display the current state of the workflow and the role of the user who is accessing the list display in advance, and suggest in advance what work can be performed next. Therefore, the user can easily grasp in advance the contents of work to be performed next in a series of workflows for troubleshooting, thereby increasing work efficiency.

(Third Embodiment) Next, a third embodiment of the present invention will be described. In the above-described first and second embodiments, all the exchanges between the client 10 and the server 20 are performed in the form of mail except for the list display of the second embodiment. On the other hand, in the third embodiment, no mail communication is performed, and all communication is performed on a web basis.

Therefore, the client 1 of the present embodiment
0 indicates that ordinary browser software is running instead of the ordinary mail software used in the first and second embodiments. As shown in FIG. 11, the browser software includes an information list display unit 15, an input form request unit 41, a form transmission unit 42, and a notification reception unit 43 as functions.

On the other hand, the server 20 does not have the submitter check unit 23 and the identification number numbering unit 25 described in the first and second embodiments, but has a form analysis unit 44 instead. The input form 45 stored in the server 20 is created by the input form definition unit 31 on a web basis. Further, the notification unit 46 performs notification of the next fault management operation instruction and status transition according to the workflow on a web basis, not on a mail basis.

In FIG. 11, components denoted by the same reference numerals as those shown in FIGS. 1 and 9 have the same functions, and therefore detailed description thereof will be omitted.

The input form request unit 41 is provided for the server 2
This is for requesting the acquisition of a desired form from among the various input forms 45 stored in 0, and includes, for example, a browser button displayed on the screen. When this browser button is clicked with the mouse and a desired form is designated, the designated input form 4
5 is sent from the server 20. This input form 45
Is sent as an HTML browser screen itself, instead of being attached to a mail as in the first embodiment. Here, the description will be made only in the HTML format, but data such as a GIF file and a text file may be handled together.

The form transmitting section 42 prepares a report by filling necessary items in the respective items in the input form 45 obtained as described above, and transmits the report to the server 20 in the HTML format. Form analysis unit 44
Converts the form of the report sent from the client 10 into the input form 4 stored in the server 20.
Analyze by referring to FIG. Then check what kind of form it is. The form analyzing unit 44 also analyzes, based on the information written in the report, which fault the report is for, which user sent the report, and the like.

When the report is provided from the client 10, the workflow state determination unit 24 and the workflow state transition processing unit 26 perform the workflow processing as described in the first embodiment for the failure analyzed by the form analysis unit 44. Is performed. Then, the state transition and the next fault management operation instruction at that time are notified by the notification unit 46 to H.
The message is sent to the appropriate client 10 in the TML format, and is received by the notification receiving unit 43.

When the form analysis unit 44 determines that the client 10 has requested the display of a list of failures, the information list processing unit 29 creates a list from the report information in the database 21. Is sent to the client 10 in HTML format.
FIG. 12 is a flowchart illustrating an operation in the server 20 when displaying a list of failures in the third embodiment.

In the present embodiment, when a list of faults is to be displayed on the client 10 side, an input form for a list display request is obtained, necessary items are filled in, and the form is executed by sending it to the server 20 side. I do. Also,
For example, as shown in FIG. 10, by clicking with a mouse on a portion of the menu that is always displayed at the bottom of the screen and displaying “List of faults currently being handled”, a request for displaying the list is made It may be sent to the side.

In step S51 of FIG. 12, when the server 20 receives the list display request, in step S52, the form analysis unit 44 refers to the role definition information of the user defined in the workflow model 34 and performs analysis. It is determined whether the requesting user who made the request is the correct submitter.

Here, if the request is a list display request from a correct submitter, the process proceeds to step S53, and the information list processing unit 29
Reads various types of fault information already stored in the database 21 and, in the next step S54, creates a list of the fault information on a web basis. Then, in step S55, the list information created in this way is transmitted to the requesting client 10.

On the other hand, if it is determined in step S52 that the list display request is not made by the correct submitter, the process proceeds to step S56, and an error notification is sent to the client 10 that has requested the list. .

As described above, in the third embodiment, all the workflow processes of the fault management are performed in the server 20 as in the first and second embodiments described above. The exchange between the server and the server 20 is performed on an HTML-based web basis.
Therefore, compared to the first and second embodiments in which the input form is exchanged as an attached file of the mail,
It is possible to more efficiently perform report creation work and list acquisition work.

As in the second embodiment, the user can easily know what work can be performed next from the current state of the workflow by viewing the display screen as shown in FIG. Can be. Furthermore, FIG.
By clicking on the report name portion where the anchor is drawn in the display screen of 0, the corresponding input form can be automatically acquired from the server 20. Therefore, the operability of a series of operations for troubleshooting can be further improved.

Although the first to third embodiments have been described in detail, the present invention is not limited to these embodiments. For example, in each of the above embodiments, either the mail-based failure management system or the web-based failure management system has been described in principle, but both may be mixed. For example, in the third embodiment, the notification from the server 20 to the client 10 is also performed on a web basis, but this may be performed by e-mail.

Further, the flow of fault management can be, for example, as follows. That is, when failure data is sent from a client to a server by e-mail, a predetermined workflow is activated on the server. Then, the failure report is transmitted to an appropriate client defined by the workflow model by e-mail, and the state of the workflow regarding the failure is changed to the next state.

When the client receives the failure report by mail, the client performs appropriate countermeasures in response to the report. Then, when the work is completed, the client-side web browser is started, and a corresponding work completion report is input on a web basis. Then, it sends it to the server.

The server that has received the corresponding work completion report analyzes the contents of the report and changes the workflow state for the specified failure to the next state. Then, the contents of the report input on the web are checked, and if there is a problem, an instruction to return the correspondence is sent by e-mail. On the other hand, if there is no problem in the report, an email of the countermeasure completion report is sent.

(Fourth Embodiment) Next, a fourth embodiment of the present invention will be described. FIG. 13 is a block diagram illustrating a schematic configuration example of the entire failure management system according to the present embodiment.

As shown in FIG. 13, the fault management system according to the present embodiment has a LAN (Local Area Network) in which a plurality of clients 10, 10,...
Is connected to another network 60 via the Internet 50 or the like. And
Client 7 connected to another network 60
The server 20 can also be accessed from 0, 70,. in this way,
In the present embodiment, failure management when software is distributed and developed by a plurality of organizations, projects, companies, and the like is described.

In the fourth embodiment, the exchange between the clients 10 and 70 and the server 20 is performed by mixing both the mail base and the web base. For example, the notification from the server 20 to the clients 10 and 70 is performed on a mail basis, and the other parts are performed on a web basis. Therefore, the clients 10, 7 of the present embodiment
0 indicates that normal mail software and normal browser software are running.

FIG. 14 is a diagram showing a detailed functional configuration of the fault management system according to the present embodiment. The same blocks as those shown in FIG. 11 are denoted by the same reference numerals, and redundant description will be omitted. . Here, the client 10
Is described, but the same applies to the client 70.

In FIG. 14, the browser software running on the client 10 functions as a login unit 51 in addition to the information list display unit 15, the input form request unit 41, and the form transmission unit 42 shown in the third embodiment. It is prepared as. The mail software running on the client 10 has at least the notification receiving unit 52 as a function.

The log-in section 51 is provided for the client 10
The user performs a process for logging in to the workflow system for failure management, and inputs user information such as a user name and a password here. This password registration is performed by the password registration unit 53 of the administrator terminal 30. That is, the administrator using the administrator terminal 30 issues a password specific to the user using the password registration unit 53 in response to a request from the user who wants to participate in the workflow. The issued password is provided to the server 20 together with the user name and stored as the password file 54, and is notified to the corresponding user in some form.

In the fault management system of this embodiment, a plurality of workflows are defined so that each can be operated individually. Therefore, the input form definition unit 31 uses the web-based input form 4
5 is defined for each workflow. The workflow definition unit 32 also defines a workflow model 34 for fault management for each workflow. Further, the password registration unit 53 issues a user password for each workflow,
register.

In this case, the workflow state determination unit 24, the workflow state transition processing unit 26, the information list processing unit 29, the form analysis unit 44, and the user authentication unit 5 in the server 20
5 and the notification unit 57 determine which workflow is currently targeted by referring to the form of the various reports sent from the client 10 and the information described therein, and according to the result, Execute the process related to the corresponding workflow.

[0118] The user authentication unit 55
The user name and the password input from the login unit 51 of the server 20 are compared with the user name and the password stored in the server 20 as the password file 54,
Authenticates whether the logged-in user can participate in the failure management workflow. At this time, the user authentication unit 55 may not be able to log in the same user to all the workflows, and may be allowed to log in by giving a password to only some of the workflows. Execute user authentication.

The ON / OFF switching section 56 switches whether the function of the user authentication by the user authentication section 55 is ON or OFF in accordance with an instruction from the administrator terminal 30. When the user authentication function is turned on, it is necessary to input a password in addition to a user name in order to log in to a desired workflow system. On the other hand, when the user authentication function is turned off, it is not necessary to input a password to log in to a desired workflow system. It is not necessary to enter the user name.

The notifying section 57 gives a mail-based notification of the next fault management work instruction or status transition according to the workflow. At this time, in addition to the notification content as described above, the notification unit 57 provides link information (URL (Uniform) of the page) to a web page to be started next according to the notification content.
Resource Locator) or link message). The user who has received the notification mail can immediately open the specified linked web page by clicking on the link information described therein.

Note that the mail used here may be received by mail software in the client 10, or may be one that can be transmitted and received with a web browser. With the latter method, if you have a web browser, you can send and receive emails and browse web pages,
Unlike mail software that requires direct access to a mail server, it can be accessed anywhere.
Alternatively, software provided with a function of transmitting and receiving mail and a function of browsing a browser, such as those provided by Netscape Communications or Microsoft, may be used.

FIG. 15 shows that the client 20
11 is a flowchart showing an operation in the client 10 performed when a status change notification mail is sent to 0. In step S61 of FIG. 15, when the client 10 receives the status change notification mail, the user proceeds to the next step S62, where U is written in the body of the notification mail.
Click RL. In response, in step S63, the web browser in the client 10 is activated.

Next, at step S64, the login section 51
Checks the log-in status of the user and determines in step S65 whether or not the user has already logged in. If the user has not yet logged in, the user authentication process is performed in step S66, and then the web page specified by the URL is opened. On the other hand, if the user has already logged in, the URL is skipped without performing the process of step S66.
Immediately open the web page specified by. The user performs the following processing according to the opened web page.

FIG. 16 is a flowchart showing the operation of user authentication in step S66. 16, first, in step S71, the user of the client 10 inputs his / her user name and password using the login unit 51. In this case, it is necessary to input a user name and a password corresponding to the workflow to log in. The input information is transmitted to the user authentication unit 55 in the server 20.

Next, in step S72, the user authentication section 55 collates the user name and password sent from the login section 51 of the client 10 with the user name and password stored in the password file 54 for each workflow. Then, it is confirmed in step S73 whether or not the user who has logged in can surely participate in the workflow. Here, if the confirmation is obtained, the process proceeds to the next processing, and if the confirmation is not obtained, step S7 is performed.
Return to 2.

FIG. 17 is a diagram showing the operation shown in FIGS. 15 and 16 as a screen image. FIG. 17 (a)
Indicates a state change notification e-mail sent from the server 20 to the client 10. In the body of the notification mail, the URL of the web page to be started next according to the notification content is described in addition to the content such as the subject of the failure and the submitter as shown in FIG. The URL includes information such as which workflow is in which case and which state is currently in progress.

Therefore, the user who has received the notification mail can access an appropriate web page without being particularly conscious by simply clicking the URL described therein. At this time, if the user has already logged in, a web page describing the details of the notification content as shown in FIG. 17C is immediately opened without performing the user authentication process. This web page has not only a detailed display of the notification contents but also a function for the user to input necessary information and send it to the server 20. For example, it is possible to use a method in which a countermeasure method is entered for a failure report notification, sent to the server 20, and registered in the database 21.

On the other hand, if the user has not yet logged in to the corresponding workflow, a log-in screen as shown in FIG. 17B is displayed to prompt the user to log in. In response, the user enters his or her username and password. In the title bar of this screen, the workflow name determined by the system from the URL is displayed, so even if the user is participating in multiple workflows, it is possible to recognize which user name and password to enter. it can. When user authentication is performed in accordance with the entered user name and password, a web page as shown in FIG. 17C is opened thereafter.

As described above, in the fourth embodiment, since the server 20 is provided with the user authentication unit 55, the workflow system for managing failures does not need to be configured by groupware, and distributed development of software can be performed. In such a case, unlike a conventional system in which only users fixed in advance by groupware can participate in a failure management workflow, any user who has been authenticated can easily participate. . Moreover,
By performing user authentication, participation of an unregistered user can be rejected, and security can be improved.

Further, in this embodiment, a plurality of workflows are operated in one fault management system, and a different password is set for each workflow to perform user authentication separately. Even the same user,
It is not necessary to show information on all workflows running in the system, and it may be possible to allow participation only for a specific workflow. However, according to the present embodiment, such a request can be handled. , Higher quality security can be realized.

In the present embodiment, the user authentication function can be switched between ON and OFF, so that the software development can be performed by a relatively small number of people. In a case where the operation is performed in an isolated network as shown in FIG. 2, by turning off the user authentication function, the trouble of inputting a user name and a password when logging in can be omitted. By providing the ON / OFF switching unit 56 in this way, it is possible to flexibly cope with both the case where software development is distributed among a plurality of organizations and the like and the case where software development is performed in a single organization determined in advance. can do.

The fault management system according to each of the embodiments described above includes a computer CPU or MPU,
It is configured by a RAM, a ROM, and the like, and can be realized by operating a program stored in the RAM or the ROM. Therefore, a program that causes a computer to operate to perform the above functions is stored in, for example, a CD-RO.
This can be realized by recording the data on a recording medium such as M and reading it into a computer. In addition to the CD-ROM, a floppy (registered trademark) disk, a hard disk, a magnetic tape, a magneto-optical disk, a nonvolatile memory card, and the like can be used as the recording medium.

The functions of the above-described embodiments are realized when the computer executes the supplied program, and the program is executed by an OS (operating system) or other application software running on the computer. When the functions of the above-described embodiment are realized in cooperation with the computer, or when all or a part of the processing of the supplied program is performed by a function expansion board or a function expansion unit of a computer, the functions of the above-described embodiment are realized. Such a program is also included in the embodiment of the present invention.

[0134]

As described above, according to the present invention, the client is provided with at least the data input / output function of the web or mail, and the server performs the workflow processing based on the fault management business data sent from the client. Since the workflow processing means is provided, workflow processing for failure management is performed only according to the program in the server, and data exchange with the client required for performing the failure management work is simply performed using the web function or the mail function. be able to. Therefore, the client does not need to have a program for workflow processing, and only needs to have a normal web function or mail function.

Thus, even when the workflow of the fault management is changed or the role of the user who works on the client side is changed, the program on the individual client is updated only by updating the program on the server side. You don't have to. Further, even when the fault management system of the present invention is constructed through a large network, it is not necessary to modify a program of a so-called gateway device for interconnecting systems of different protocols. Therefore, according to the present invention, the work of updating and managing the workflow is greatly simplified, and the labor and time required for maintenance of the failure management system can be significantly reduced.

Further, according to the present invention, the client does not need to have a workflow program at all.
Memory usage on the client side can be saved. As a result, it is possible to release more system resources on the client side than in the past, and it becomes impossible to start an application other than the fault management system on the client side, or even if it can be started, it will not operate well. The inconvenience described above can be avoided.

According to another feature of the present invention, a list of faults that have occurred is created, and the list is transmitted to the client for display. Thus, it is possible to see a list of the progress of the workflow for each of these faults and the like, and it is possible to assist in performing the task of fault management.

Further, according to another feature of the present invention, with respect to a fault being handled, a list of work that can be performed next from the current state is created and transmitted to the client for display. The user can easily grasp in advance the contents of work to be performed next in a series of workflows for troubleshooting, thereby improving work efficiency.

According to another feature of the present invention, when data is exchanged between a client and a server by e-mail, an ID required to cope with a failure is provided by e-mail which is not directly visible to the user. The client user does not need to be aware of the ID at all, and can perform the task of fault management simply by exchanging the necessary e-mails. Can be improved.

According to another feature of the present invention, user authentication is performed using user information sent from the client and user information registered in the server in advance.
Since the user who has been authenticated is allowed to participate in the workflow process, the fault management system does not need to be configured with groupware. The required user can participate in the workflow if the user is authenticated without performing a troublesome operation such as installing a groupware program on the client. In addition, since participation of a user who has not been authenticated can be refused, security problems can be solved.

According to another feature of the present invention, when a plurality of different workflows are processed in one fault management system, user authentication is performed for each of a plurality of different workflows. In addition, it is possible to allow participation only in a specific workflow among a plurality of workflows operating in the system, and it is possible to realize higher quality security.

According to another feature of the present invention, the user authentication function can be switched ON / OFF. For example, when software development is performed in a fixed organization or the like, the user authentication function can be changed. By turning off the authentication function, it is possible to save the trouble of inputting user information such as a user name and a password when logging in. As described above, by switching the presence or absence of the user authentication function, it is possible to flexibly cope with both the case where software is distributedly developed and the case where software is not developed.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a detailed functional configuration example of a fault management system according to a first embodiment.

FIG. 2 is a block diagram illustrating a schematic configuration of the entire fault management system according to the first to third embodiments;

FIG. 3 is a flowchart illustrating a procedure when an input form and a workflow model are defined by an input form definition unit and a workflow definition unit.

FIG. 4 is a flowchart showing a procedure for defining a template of an input form in step S3 of FIG. 3;

FIG. 5 is a flowchart illustrating an operation when a client obtains an input form template stored in a server.

FIG. 6 is a flowchart showing an operation when a report created based on an input form is submitted from a client to a server.

FIG. 7 is a flowchart showing an operation of a main process shown in FIG. 6;

FIG. 8 is a diagram showing an example of a screen display of a notified failure report.

FIG. 9 is a block diagram illustrating a detailed functional configuration example of a fault management system according to a second embodiment;

FIG. 10 is a diagram illustrating an example of a screen display of a failure list displayed on an information list display unit.

FIG. 11 is a block diagram illustrating a detailed functional configuration example of a fault management system according to a third embodiment.

FIG. 12 is a flowchart illustrating an operation in the server when displaying a list of failures in the third embodiment.

FIG. 13 is a block diagram illustrating a schematic configuration of an entire fault management system according to a fourth embodiment.

FIG. 14 is a block diagram illustrating a detailed functional configuration example of a fault management system according to a fourth embodiment;

FIG. 15 is a flowchart showing an operation in the client performed when a status change notification mail is sent from the server to the client.

FIG. 16 is a flowchart showing an operation of user authentication in step S66 of FIG.

FIG. 17 is a diagram showing a screen image of the operation shown in FIGS. 15 and 16;

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 10 Client machine 11 E-mail transmission part 12 E-mail reception part 13 E-mail reply part 14 File attachment part 15 Information list display part 20 Server machine 21 Database 22 E-mail server 23 Submitter check part 24 Workflow status judgment part 25 Identification number numbering part 26 Workflow State transition processing unit 27 State transition notification unit 28 Information list processing unit 29 Information list processing unit 30 Administrator terminal 31 Input form definition unit 32 Workflow definition unit 33 Input form 34 Workflow model 40 Network 41 Input form request unit 42 Form transmission unit 43 Notification receiving unit 44 Form analysis unit 45 Input form 46 Notification unit 50 Internet 51 Login unit 52 Notification receiving unit 53 Password registration unit 54 Password file 55 User authentication unit 5 ON / OFF switching section 57 notification unit 60 LAN 70 client machines

 ────────────────────────────────────────────────── ─── Continued on the front page (72) Inventor Toshimitsu Baba 2-6-3 Otemachi, Chiyoda-ku, Tokyo F-term in Nippon Steel Corporation (reference) 5B042 GA12 JJ02 MC15

Claims (31)

[Claims] 1. A failure management system configured by a client-server system for managing failures occurring on software in accordance with a workflow, wherein the client and the server have at least a data input / output function by a web, and the server is Furthermore, based on the fault management business data input and transmitted by the web function of the client, the system further comprises a workflow processing means for performing the processing of the workflow, performing the processing of the workflow only in the server, and accompanying the workflow. A fault management system, wherein various notifications between a client and a server are performed by the data input / output function using the web. 2. The server according to claim 1, wherein the server stores and manages fault management business data input and transmitted by a web function of the client, and fault management stored and managed by the fault information management means. List processing means for creating a list of faults that have occurred using business data and transmitting the list to the client, wherein the client displays a list of faults created and sent by the list processing means The fault management system according to claim 1, further comprising a display unit. 3. The server uses the fault management business data stored and managed by the fault information management means to create a list of operations that can be performed next from the current state with respect to the fault being handled. 2. The system according to claim 1, further comprising: a work information processing unit for transmitting to the client, wherein the client further includes a work list display unit for displaying work list information created and transmitted by the work information processing unit. Or the fault management system according to 2. 4. A failure management system configured by a client-server system for managing failures occurring on software in accordance with a workflow, wherein the client and the server have at least a data input / output function by mail, and the server is Further, an ID assigning means for assigning a unique ID to the fault that has occurred, and a correspondence with the fault is detected based on the ID included in the fault management business data sent by the mail function of the client. Workflow processing means for performing the workflow processing based on the fault management business data, performing the workflow processing only in the server, and sending various notifications between the client and the server associated with the workflow by the mail. The feature is that it is performed by the data input / output function. Fault management system. 5. The fault management system according to claim 4, wherein the ID is included in a header part of the mail. 6. The server according to claim 1, wherein the server stores and manages fault management business data including the ID sent by the mail function of the client, and the server stores and manages the fault management business data. List processing means for creating a list of faults that have occurred using the fault management business data and transmitting the list to the client by a mail function, wherein the client is a fault created and sent by the list processing means. The fault management system according to claim 4, further comprising a list display unit that displays a list of items. 7. A fault management system comprising a client server system for managing faults occurring on software according to a workflow, wherein the client and the server have at least a data communication function, and the server further comprises Workflow processing means for performing the above-mentioned workflow processing based on the fault management business data sent from the client, performing the above-mentioned workflow processing only in the above-mentioned server, and various notifications between the client and the server accompanying the above-mentioned workflow Is performed by the data input / output function. 8. A failure management method for managing a failure occurring on software according to a workflow, wherein a first step of registering a failure occurring on the software on a server side in a client of a client-server system. A second step of, in the server, outputting a failure management operation instruction to an appropriate client in accordance with the workflow according to the registered failure, and inputting failure management operation data relating to the performed operation in the client. A third step of outputting the workflow to the server based on the fault management work data input from the client in the server. After registering the fault, the above-mentioned second to fourth steps Fault management method characterized by repeatedly performing the processing of-up. 9. The fault management method according to claim 8, wherein the exchange between the client and the server is performed by a Web input / output function. 10. The method according to claim 1, further comprising the step of, after the first step, assigning a unique ID to the registered fault at the server.
9. The failure management method according to claim 8, wherein the failure management method is performed by an input / output function using a mail including D. 11. The fault management method according to claim 10, wherein the ID is included in a header of a mail. 12. The instruction in the second step is performed by e-mail, the failure management work data in the third step is input by a web function, and the workflow processing in the fourth step is input by the web function. 9. The fault management method according to claim 8, wherein the fault management is performed based on the fault management business data. 13. A failure management apparatus for managing a failure occurring on software in a server configured by a client-server system in accordance with a workflow, based on failure management business data sent from a client. And a workflow processing unit for performing a process of the workflow and notifying a client defined in the workflow of a predetermined notification. 14. A fault information management means for storing and managing fault management business data sent from the client, and a fault generated using the fault management business data stored and managed by the fault information management means. 14. The fault management apparatus according to claim 13, further comprising: a list processing unit that creates and transmits a list of the list. 15. Using the fault management business data stored and managed by the fault information management means, create list information of work that can be performed next from the current state in accordance with a predetermined workflow for a fault being handled. 14. A work information processing means for transmitting the work information.
Or the fault management device according to 14. 16. A fault management device for managing faults occurring on software in a server configured by a client-server system according to a workflow, wherein each time a fault is registered, an ID unique to the fault is registered. I to grant
D providing means, and detecting a correspondence with the failure based on the ID included in the failure management business data transmitted by the mail function of the client, and executing the workflow based on the failure management business data. A failure management device, comprising: a workflow processing unit that performs processing and performs a predetermined notification by including the ID in a mail to a client defined in the workflow. 17. The fault management device according to claim 16, wherein the ID is included in a header part of the mail. 18. A fault information management means for storing and managing fault management business data including the ID sent by the mail function of the client, and a fault management business stored and managed by the fault information management means. 18. The fault management device according to claim 16, further comprising: a list processing unit that generates a list of faults that have occurred using data and transmits the list by a mail function. 19. The method according to claim 1, wherein
A computer-readable recording medium on which a program for causing a computer to function as each of the means described in the section is recorded. 20. A computer-readable recording medium on which a program for causing a computer to execute the processing procedure of the fault management method according to claim 8 is recorded. 21. A fault management system comprising a client server system for managing faults occurring on software according to a workflow, wherein the client and the server have a data input / output function by at least one of a web and a mail. The server further includes a workflow processing unit that performs the workflow processing based on the fault management business data input and transmitted by the data input / output function of the client, user information transmitted from the client, and Authentication means for performing user authentication using user information registered in advance in the server, performing processing of the workflow only in the server, and transmitting various notifications between the client and server associated with the workflow to the data Depending on the input / output function As well as the Migihitsuji, fault management system characterized in that the user of the user authentication has been performed to allow participation in the process of the workflow. 22. The method according to claim 21, wherein the workflow processing unit executes processing of a plurality of different workflows, and the user authentication unit performs the user authentication for each of the plurality of different workflows.
Fault management system according to the above. 23. The fault management system according to claim 21, further comprising switching means for switching ON / OFF of the user authentication function by said user authentication means. 24. A failure management method for managing a failure occurring on software according to a workflow, wherein a first step of registering a failure occurring on the software on a server side in a client of a client-server system. A second step of, in the server, outputting a failure management operation instruction to an appropriate client in accordance with the workflow according to the registered failure, and inputting failure management operation data relating to the performed operation in the client. A third step of outputting the workflow to the server based on the fault management work data input from the client in the server. After registering the fault, the above second to fourth steps The processing of the first and third steps is performed at an arbitrary stage by performing the user authentication based on the user information input in the client and the user information registered in the server in advance. A failure management method, wherein the failure management method is performed by a user who has received and participated in the processing of the workflow. 25. The fault management according to claim 24, wherein processing of a plurality of different workflows is performed in the same system, and the user authentication is performed for each of the plurality of different workflows. Method. 26. ON / OFF of the user authentication function
26. The fault management method according to claim 24, wherein the user authentication is executed only when the function is turned on. 27. A failure management apparatus for managing a failure occurring on software in a server configured by a client-server system according to a workflow, based on failure management work data sent from a client. A workflow processing unit that performs processing of the workflow, and performs a predetermined notification to a client defined by the workflow; and user information sent from the client and user information registered in the server in advance. A failure management device comprising: an authentication unit that performs user authentication by using the authentication unit. 28. The method according to claim 27, wherein the workflow processing unit executes processing of a plurality of different workflows, and wherein the user authentication unit performs the user authentication for each of the plurality of different workflows.
The fault management device according to 1. 29. The fault management apparatus according to claim 27, further comprising a switching unit that switches ON / OFF of the function of the user authentication by the user authentication unit. 30. A computer-readable recording medium having recorded thereon a program for causing a computer to function as each means according to any one of claims 21 to 23 and 27 to 29. 31. A computer-readable recording medium on which a program for causing a computer to execute the processing procedure of the fault management method according to claim 24 is recorded.