JP2015095131A - Failure recording management device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To perform support such that matched failure recording can be created, in an operation maintenance task of an information system managed by a plurality of vendors.SOLUTION: A failure recording management device has: a coping situation database associating and storing a start date at which failure coping with failure that is process information is started, an end date at which the failure coping is ended, information specifying charge of the next process of the failure coping, and information specifying an input person inputting the process information as one record; and a coping situation processing part displaying a warning when the start date corresponding to the information specifying the input person of the coping situation database is after end time of the record in which the information specifying the input person of the coping situation database is stored as the information specifying the charge of the next process.

Description

  The present invention relates to a technique for managing failure records when operation and maintenance of an information system is performed by a plurality of vendors.

  In recent years, it has become common to operate and maintain information systems by multiple vendors. For example, Patent Document 1 discloses a technique related to a multi-vendor integrated maintenance management system that comprehensively manages a system constructed by combining devices obtained from a plurality of vendors. In such maintenance management by a plurality of vendors, particularly when failure information is managed, there is a current situation in which each vendor creates a failure record and manages it independently.

JP 2008-276544 A

  In such multi-vendor maintenance management, the maximum processing time is set for each vendor for failure recovery work, and a penalty is generated when the set maximum time is exceeded. It is common to be contracted to be able to

  In this case, the start time of the responsibility time for converting the penalty of each supplier is the time when the processing was taken over from the predecessor, and the time when the work is taken over by the successor is determined as the end time of the responsibility time, and whether there is a penalty To do. Since the operator manually inputs the start and end of the process, the responsibility time is determined based on the manually input start time and end time.

  The end time of this predecessor should be the same as the start time of the successor (the time of responsibility of the successor begins when the successor finishes the process and throws the subsequent process to the successor). . However, since it is manual input, it is conceivable that an error mismatch occurs in the input time. In such a case, in order to clarify the location of the penalty at a later date, the correct time will be confirmed with each other and the input will be corrected, which takes time.

  The present invention aims to suppress the occurrence of this input mismatch in advance in order to save such trouble.

  In order to solve the above problems, in the present invention, failure handling for one failure is divided into a plurality of steps, start date information that started for each step, end date information that ended the failure handling, and responsible for the next step Information, a process information database that stores process information in which the input person information of this process is stored as one record, and if the process information is newly input, the input person information of the input process information, The first process information that matches by comparing the information in charge of the next process in the response status database is identified, the end date / time information of the first process information is extracted, and the start date / time of the input process information And the end date / time information of the first process information is compared with the start date / time information of the input process information, and the start date / time information of the input process information is Finish Than when information, in some cases later, and a corresponding status processing section for displaying a warning.

  It is possible to support the creation of consistent failure records in the operation and maintenance of information systems managed by multiple vendors.

It is an example of a response status confirmation dialog in the failure record management apparatus of the present embodiment. It is a block diagram of the failure record management apparatus in this embodiment. It is a figure which shows an example of the failure information database which the failure information management part of this embodiment hold | maintains. It is a figure which shows an example of the response status database which the response status management part of this embodiment hold | maintains. It is a figure which shows an example of the responsibility determination database which the responsibility determination management part of this embodiment hold | maintains. It is an example of a failure information input screen in the failure record management apparatus of this embodiment. It is an example of a response status input screen in the failure record management apparatus of the present embodiment. It is an example of an input confirmation dialog in the failure record management apparatus of this embodiment. It is an example of a responsibility determination dialog in the failure record management apparatus of the present embodiment. It is an example of a responsibility determination confirmation dialog in the failure record management apparatus of the present embodiment. It is a flowchart which shows the incident information new input and update input procedure to the failure record management apparatus in this embodiment. FIG. 12 is a flowchart showing a new incident information input / update input procedure to the failure record management apparatus in this embodiment, which is a continuation from FIG. It is a flowchart which shows the incident information close procedure to the failure record management apparatus in this embodiment.

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

  FIG. 1 is an example of a response status confirmation dialog screen. When a failure occurs, according to each failure response, the failure response information such as the start time and end time of the failure response is input to the system, but a warning is given if the input time may need to be corrected Is displayed in the correspondence status confirmation dialog 1000. The correspondence status confirmation dialog 1000 includes an inconsistency information display unit 1001, a no problem button 1002, an input content correction (self) button 1003, and an input content correction request button 1004. When it is determined that there is a possibility of inconsistency in the failure record management apparatus 100, the user confirms the content, and there is no problem 1002, input content correction (self) 1003, and input content correction request 1004. Press the button.

  FIG. 2 is an overall configuration diagram including the failure record management apparatus 100 and the vendor terminal 110 connected to the failure management recording apparatus 100 according to the embodiment of the present invention. As shown in FIG. 2, the present embodiment includes a failure record management apparatus 100, vendor terminals 110 and 120, and a communication network 130. Any number of vendor terminals can be installed. The failure record management apparatus 100 has a failure information database 101, a response status database 102, and a responsibility determination database 103. As a function for processing these databases, a failure information processing unit 104, a response status processing unit 105, and a responsibility determination processing unit 106 are provided. In addition, the communication processing unit 107 is provided as a function of communicating with the vendor terminals 110 and 120. The processing performed by the failure record management device 100 is a CPU that is an arithmetic device and is expanded and processed in a memory that is a temporary storage device.

  The vendor terminal 110 (120) includes a browsing processing unit 111 (121) that can display an operation screen of the failure record management apparatus 100. The vendor terminal 110 (120) realizes data input and reference to the failure record management apparatus 100 via the communication network 130. The processing performed by the vendor terminal 110 (120) is a CPU that is an arithmetic device and is expanded and processed in a memory that is a temporary storage device.

  FIG. 3 is a diagram illustrating an example of a failure information data configuration held in the failure information database 101. The failure information database 101 includes an incident ID 401, a failure name 402, contents 403, a failure occurrence system 404, a failure occurrence date / time 405, a failure handling completion date / time 406, and a failure cause 407. The incident ID 401 is a number for identifying failure information, and is a unique number in this system. Incident ID 401 is automatically and sequentially recorded by the failure information processing unit 104. After the failure occurs, the user inputs the failure name 402, the content 403, the failure occurrence system 404, and the failure occurrence date and time 405. The failure record management apparatus 100 extracts the same failure using the input failure occurrence system 404 and failure occurrence date / time 405 information. Further, when the failure is resolved, the failure response completion date and time 406, the failure cause 407, and the responsible location 408 are input.

  FIG. 4 is a diagram illustrating an example of the configuration of failure response status data held in the response status database 102. The response status database 102 includes an incident ID 501, response status ID 502, start date and time 503, end date and time 504, response content 505, next process person in charge 506, response completion 507, input person (company) 508, input person (user) 509, correction request 510. The incident ID 501 is associated with the incident ID 401 in the failure information database 101, and a plurality of response status data can be associated with one failure information data. The correspondence status ID 502 is a number for identifying the correspondence status, and is a unique number in the present system. Since a plurality of failures are dealt with for one failure, a plurality of response status IDs are associated with one incident ID that specifies failure information. It can be understood that even if the response status IDs are different and the failure responses are different, if the incident IDs are the same, the response is the same failure. The response status ID 401 is automatically and sequentially recorded by the response status processing unit 102. The user inputs the start date and time 503, the end date and time 504, the correspondence contents 505, and the next process person in charge 506 after performing the work. When all the actions to be performed by the user are completed, the user inputs the action completion 507. An input person (company) 508 and an input person (user) 509 identify the user (user) who is inputting on the failure record management apparatus 100 side and automatically input it. Since the user logs in to the failure record management apparatus 100 and uses the user, the user is identified and automatically input based on the login information. In this embodiment, the automatic input is performed. However, the present invention is not limited to this, and control may be performed so that the user himself / herself inputs information for identifying himself / herself. The failure record management apparatus 100 identifies the information input to the next process person in charge 506 and the input person (company) 508, and performs the consistency check described in steps 211 to 216 in the input flow of FIG. When inconsistency occurs and the user makes a correction request from the screen of the response status confirmation dialog 1000, whether the correction request has been made is recorded in the correction request 510. The correspondence status database 102 is created for each input person, and the created records are called process information.

  FIG. 5 is a diagram illustrating an example of the configuration of failure responsibility determination data held in the responsibility determination database 103. The responsibility determination database 103 includes an incident ID 601, a failure occurrence system 602, a failure cause 603, a responsible location 604, an input person (company) 605, an input person (user) 606, and a responsibility determination confirmation 607. The incident ID 601 is associated with the incident ID 401 in the failure information database 101, and one responsibility determination data is associated with one failure information data. In the failure occurrence system 602, the same information as the failure occurrence system 404 in the failure information database 101 is set. The failure cause 603 is set with the same information as the failure cause 407 in the failure information database 101. In the failure information 604, responsible location information input by the user is recorded. An input person (company) 605 and an input person (user) 606 identify the user who is inputting on the failure record management apparatus side and automatically input the user. Since the user logs in to the failure record management apparatus 100 and uses the user, the user is identified and automatically input based on the login information. In this embodiment, the automatic input is performed. However, the present invention is not limited to this, and control may be performed so that the user himself / herself inputs information for identifying himself / herself. In the responsibility determination confirmation 607, the confirmation result by the user input at the responsibility location 604 is recorded.

  FIG. 6 is an example of a failure information input screen. The failure information input screen 700 has an incident ID 701, a failure name 702, contents 703, a failure occurrence system 704, a failure occurrence date and time 705, a response completion date and time 706, a failure cause 707, and a registration button 708. Incident ID 701 is automatically assigned by the failure information processing unit 101. The user inputs a failure name 702, contents 703, failure occurrence system 704, failure occurrence date / time 705, response completion date / time 706, and failure cause 707. After input, the registration 708 is pressed.

  FIG. 7 is an example of a response status input screen. The response status input screen 800 includes a start time 801, an end time 802, a response status 803, a next process person in charge 804, a response status addition button 805, a response completion check button 806, a registration button 807, and a correction request message display field 808. The user inputs start time 801, end time 802, response status 803, and next process person in charge 804. When it is desired to input a plurality of response statuses 800, the user presses an add response status button 805. When the work to be performed for the corresponding failure is completed, the user selects the response completion check button 806. After input, the registration 807 is pressed. If an inconsistency is found in the response status and there is a correction request from another user, a message is displayed in the correction request message display field 808.

  FIG. 8 is an example of an input confirmation dialog screen. The input confirmation dialog 900 includes a failure information display unit 901, a failure information selection unit 902, and a new registration selection unit 903. The failure record management apparatus 100 obtains, from the failure information database 101, failure information within 24 hours before and after the failure occurrence date and time input by the same failure occurrence system from the failure occurrence system 704 and failure occurrence date and time 705 inputted by the user. Extract. The failure record management apparatus 100 displays the extracted failure information on the failure information display 901. The user selects any of the extracted failure information and checks the failure information selection unit 902. Or when registering process information newly, the new registration selection part 903 is selected and checked.

  FIG. 9 is an example of a responsibility determination dialog screen. The responsibility determination dialog 1100 includes a failure information display unit 1101, a responsibility determination tendency display unit 1102, a responsibility location selection unit 1103, and an OK button 1104. The failure record management apparatus 100 displays the failure occurrence system 404 and the failure cause 407 recorded in the failure information database 101 in the failure information display unit 1101. Further, the responsibility judgment tendency display unit 1102 extracts process information that becomes the same fault occurrence system 602 and fault cause 603 from the responsibility judgment database 103, and displays which company has been input as the responsible location so far. . The user selects and checks which company is responsible for the current failure in the responsible location selecting unit 1103. When the OK button 1104 is clicked after that, the failure record management apparatus 100 displays a responsibility determination confirmation dialog 1200 for the input user of the responsible location 1103.

  FIG. 10 is an example of a responsibility determination confirmation dialog. The responsibility determination confirmation dialog 1200 includes a failure information display unit 1201, a responsibility determination trend display unit 1202, a responsibility location display unit 1203, an OK button 1204, and an NG button 1205. The failure record management apparatus 100 displays the failure occurrence system 404 and the failure cause 407 recorded in the failure information database 101 on the failure information display unit 1201. Further, the responsibility determination tendency display unit 1202 extracts the failure response that becomes the same failure occurrence system 602 and the failure cause 603 from the responsibility determination database 103, and displays which company has been input as the responsible location so far. . The responsibility location display unit 1203 displays the responsibility location 604 of the responsibility determination database 103. The user confirms the contents and presses an OK button 1204 or an NG button 1205.

  FIG. 11 and FIG. 12 are flowcharts of processing procedures in the vendor terminal 110 (120) and the failure record management apparatus 100 in the failure response information new input and update input of this embodiment. The warning display when the vendor inputs the failure handling time will be described below with reference to the flowcharts of FIGS.

  In step 201, the user accesses the failure record management apparatus 100 using the vendor terminal 110 (120), inputs a pre-registered user ID and password, and makes a login authorization application.

  In step 202, the failure record management apparatus 100 authenticates the user ID and password, and if authorization is not received, the user is requested to input again.

  In step 203, when the login authorization is received, the screen transitions to the menu selection screen of the failure record management apparatus 100. When new registration of process information is selected, a failure information input screen 700 is displayed.

  In step 204, the user inputs the failure occurrence system 704 and the failure occurrence date and time 705 on the failure information input screen. FIG. 5 shows an example in which the financial accounting system is input to the failure occurrence system 700 and 2013/1/15 11:45 is entered as the failure occurrence date and time.

  In step 205, the failure information processing unit 104 of the failure record management apparatus 100 searches the failure information database 101 and searches the recorded failure occurrence system 404 for the same system as the entered failure occurrence system 704. To do. If extracted, it is determined that there is a possibility that the same failure information has already been input, and the process proceeds to step 206. If not extracted, it is determined that the same failure information has not been input, and the process proceeds to step 210.

  In FIG. 5, since the financial accounting system is input to the failure occurrence system 700, and the failure occurrence system 404 is also recorded as the financial accounting system in the input example 1 of FIG. 5, the record of the input example 1 is extracted.

  In step 206, when the same failure occurrence system 704 inputted by the user is extracted from the failure information database 101, it has occurred within 24 hours before and after the failure occurrence date and time 705 inputted by the user. The failure occurrence date and time 405 of the failure information database 101 is searched for whether it is a failure. If it is extracted, it is determined that there is a possibility that the same failure information has already been input, and the process proceeds to step 207. If not extracted, it is determined that the same failure information has not been input, and the process proceeds to step 210.

  In FIG. 5, 2013/1/15 11:45 is input as the failure date and time, and in the input example 1 of FIG. 5, 2013/1/15 12:00 is input. Since this is within 24 hours before and after, the failure record management apparatus 100 interprets that it is within the error range, and the record of the input example 1 is extracted.

  In step 207, if the failure occurrence date and time 705 and the failure information that occurred within 24 hours before and after are found in the failure information database 101, the failure record management device 100 is identical to the failure occurrence system 704 input by the user. Is already input, and an input confirmation dialog 900 is displayed. The failure information extracted in step 206 is displayed on the display part of the dialog. A selection button 902 is displayed for each failure information.

  In addition to the failure information, a new registration selection button 903 is displayed. If the failure information to be input matches the displayed failure information, the user presses the selection button 902, and if not, the user presses the selection button 903 and proceeds to step 208.

  In step 208, the failure record management apparatus 100 determines that the same failure information is not registered in the failure information database 101 but is newly registered failure information, and displays the failure information input screen 700 again. The user arbitrarily inputs a name that indicates the content of the failure in the failure name 702, arbitrarily inputs the content of the failure in the content 703, and inputs the date and time of the failure when the response is completed in the response completion date and time 706. For the cause 707, an event that causes the failure is selected from the list and input. The incident ID 701 does not need to be input by the user, and the system gives an arbitrary ID. In the present embodiment, the failure record management apparatus 100 identifies the largest numerical value from all the incident IDs 401 recorded in the failure information database 101, and automatically assigns the number plus 1 to that value. For example, when the incident ID 401 is registered up to “INC0002” in the failure information database 101, the incident ID “INC0003” is automatically assigned to the newly registered failure information. After inputting each item, the user presses a registration button 708.

  In step 209, the failure information processing unit 104 of the failure record management apparatus 100 registers the input information in the failure information database 101. The entered incident ID 701 is the database item incident ID 401, the entered failure name 702 is the database item failure name 402, the entered content 703 is the database item content 403, and the entered failure occurrence system 704 is the database The failure occurrence date / time 705 input to the failure occurrence system 404 of the item is the failure occurrence date / time 405 of the database item, the response completion date / time 706 input is the response completion date / time 406 of the database item, and the failure cause 707 input is the database Each item is stored in the cause of failure 407.

  In step 210, the failure record management apparatus 100 displays a response status input screen 800. The user inputs the work history performed by himself / herself in dealing with the failure as a start time 801, an end time 802, and correspondence contents 803. In addition, when a work request is made to another vendor as the next process of the corresponding work, the vendor name of the request destination is input to the next process person 804. When it is desired to input the work history in a plurality of times, a response status input screen 800 is newly displayed by pressing a response status addition button 805.

  If the user determines that all the work that he / she should perform for the corresponding failure response has been completed, the response completion check box 806 is selected. When the input is completed, a registration button 807 is pressed. The information input here is stored in an item related to the corresponding incident ID 501 in the response status database 102.

  In FIG. 6, “2013/1/15 12:05” at the start time 801, “2013/1/15 13:05” at the end time 802, “cause investigation is performed in the response status 803, and it is a software failure. This is an example in which a response request is made to the company B who is in charge of software maintenance, “the company B” is checked in the next process person 804, and the response completion check box 806 is checked.

  The response status processing unit 105 of the failure record management device 100 has no contradiction between the input content of step 210 and the input content of another user when another vendor has registered the response status for the same failure response. And display a warning based on the result of the verification.

  In step 211, it is confirmed from the response status database 102 whether another user has already input the response status for the target failure information. As a procedure, the incident ID 501 in the response status database 102 is searched, and it is verified whether the same incident ID as the input target exists. As the incident ID input here, the user specifies the incident ID assigned when the incident ID is input to the failure information database. When the same thing exists, the input person (company) 508 is further searched, and it is verified whether it is the same company as the user from the login information of the user. If it is another company, the process proceeds to step 212. If it is not another company, the process proceeds to step 217.

  In the situation where the input example 2 of FIG. 4 has already been input, and the user inputs FIG. 7 (the same data as the input example 1 of FIG. 4), the incident ID is the same as INC0001 and is used. Therefore, the failure record management apparatus 100 determines that another vendor has already input, and the process proceeds to step 212.

  In step 212, the next process person in charge 506 of the response status database 102 verifies whether another company has registered the user as the next process. The situation where another company registers the user as the next process means that the responsibility for dealing with the failure has been transferred from the other company to the user, The response must start from the previous stage. If the user has been registered, the process proceeds to step 213. If the user has not been registered, the process proceeds to step 214.

  In input example 2 of FIG. 4 and FIG. 7 (the same data as input example 1 of FIG. 4), since the next process person in charge 506 is not registered in input example 2 of FIG. Become. If the next process person in charge 506 is a user, the process proceeds to step 213.

  In step 213, if the user is registered as a person in charge of the next process by another company, it is verified whether there is a temporal contradiction. The start date and time 801 input by the user is compared with the end date and time 504 of the correspondence status database 102. If the input start date and time 801 is after the end date and time 504, it is determined that there is a mismatch, and the process proceeds to step 216. If the start date / time 801 is the same as or earlier than the end date / time 504, it is considered that there is no inconsistency in the situation where the user is registered as the person in charge of the next process, and the process proceeds to step 214.

  In step 214, it is verified whether the user has entered another company as the person in charge of the next process in a situation where the other company has already registered the response status. The situation where the user has entered another company as the person in charge of the next process means that the responsibility for failure handling has been transferred from the user to another company. The response must start immediately or at an earlier stage. Here, as a user procedure, when the company of the next process person in charge 804 input on the response status input screen 800 exists in the next process person in charge 506 of the response status database 102, the process proceeds to step 215. If not, the process proceeds to step 216.

  In the input example 2 and FIG. 7 in FIG. 4 (the same data as the input example 1 in FIG. 4), the company B is input to the next process person 804 in FIG. 7 and exists as the input example 2 in FIG. Therefore, the process proceeds to step 215.

  In step 215, if the user has input another company as the person in charge of the next process, it is verified whether there is a temporal contradiction. The end time 802 input by the user is compared with the start time 503 of the response status database. If the end time 802 is before the start time 503, it is considered that there is a mismatch, and the process proceeds to step 216. If the end time 802 is equal to or later than the start time 503, it is considered that there is no inconsistency in the situation where another company is input as the person in charge of the next process, and the process proceeds to step 217.

  Here, it is assumed that another company (next process) has previously input the response status. In input example 2 and FIG. 7 in FIG. 4 (assuming the same data as input example 1 in FIG. 4), 2013/1/15 13:05 is input at end time 802 in FIG. In Example 2, 2013/1/15 13:05 is input at the start time 503, and since it is the same, it is considered that there is no inconsistency, and the process proceeds to Step 217. The user's input value is registered in the correspondence status database after judging inconsistency.

  In step 216, if it is determined that there is a mismatch between the input content of step 210 and the input content of another user, a warning is displayed. Specifically, a response status confirmation dialog 1000 is displayed. This is a dialog for warning whether or not the entered failure response time is really good. The content determined to be inconsistent in step 213 or step 215 is displayed on the confirmation display unit 1001. For example, when company B is designated as the next process of company A, a warning is displayed when there is a gap between the end time of company A and the start time of company B. If the work of company B is started during the work of company A, no warning is displayed. By displaying a warning, it is confirmed whether or not the input time is really acceptable. This input time is the responsibility time, and the responsibility time is the time to clarify which company is responsible. It is necessary to confirm whether it is continuous.

  The user confirms the content determined to be contradictory, and presses any button of no problem 1002, input content correction (self) 1003, and input content correction request 1004. If no problem 1002 is pressed, the process proceeds to step 217 as it is. If correction of input content (self) is pressed, the process returns to step 210. When the input content correction request 1004 is pressed, the company name is recorded in the correction request 510 for the correction request target data in the response status database 102, and the response completion 507 is set as completed. If yes, delete it and go to step 217.

  In step 217, the response status processing unit 105 of the failure record management apparatus 100 registers the input information in the response status database 102. Here, each input item is recorded in an item of the correspondence situation database 800. The input start time 801 is input to the database item start date and time 503, the input end time 802 is input to the database item end date and time 504, and the input correspondence status 803 is input to the database item corresponding content 505. The person in charge 804 is stored in the next item person in charge 506 of the database item, and the input correspondence completion 806 is stored in the database item correspondence completion 507.

  4 and 7, the start time “2013/1/15 12:05”, the end time “2013/1/15 13:05” input in FIG. 7, the response status “cause investigation and software failure “A response request is made to company B, who is in charge of software maintenance.”, “B company” in charge of the next process, and a check in the response completion check box 806 is stored in the response status database 102 as input example 1 in FIG. Has been.

  FIG. 13 is a flowchart of processing procedures in the vendor terminal 110 and the failure record management apparatus 100 regarding confirmation of responsibility determination as to who was responsible for the occurrence of a failure when the failure handling of the failure record management apparatus 100 of the present embodiment is completed. It is.

  In step 301, after receiving the login authorization, the user selects the corresponding process information, checks the response completion 806 from the response status input screen 800, and presses the registration button 807.

  In step 302, the failure record management apparatus 100 records that the response is completed in the response completion 507 of the response status database 102.

  In step 303, the failure record management apparatus 100 determines whether all vendors have been handled. As a procedure, all the corresponding response status data is extracted from the incident ID 501 of the response status database 102. The correspondence completion 507 of the target correspondence status data is confirmed, and if all are completed, the process is completed if there is data that has not been completed.

  The user then records who was responsible for the failure. It is difficult to generally determine which company is responsible for the occurrence of a failure, depending on the situation of the failure. Therefore, the final decision on the responsibility for the occurrence of a failure is made by the user. However, in order to make it easier for the user to make a determination, the failure record management apparatus 100 provides a support when the user determines the responsibility for the occurrence of a failure by displaying the tendency of the occurrence responsibility for a similar failure in a dialog.

  In step 304, the failure record management apparatus 100 displays a responsibility determination dialog 1100. In the system summary display field 1101, the failure occurrence system 404 and the failure cause 407 are displayed from the failure information database 101. The responsibility judgment tendency display column 1102 extracts the same fault information from the fault occurrence system 602 and fault cause 603 of the responsibility judgment database 103, and to which company the responsible location 604 is set. The number of cases is displayed. In the responsibility determination selection column 1103, all companies involved in the corresponding failure handling are displayed from the input person (company) 508 of the failure handling data table 500. The user checks the company that seems to be responsible for the failure. After checking one of the companies, the user presses OK 1104.

  In step 305, the responsibility determination processing unit 106 of the failure record management apparatus 100 registers the input information in the responsibility determination database 103. Here, each input item is recorded in an item of the responsibility determination database 103. The incident ID of the corresponding process information is the incident ID 601 of the database item, and the failure occurrence system 404 displayed in the system summary display column 1101 is the failure cause displayed in the system summary display column 1101 of the failure occurrence system 602 of the database item. 407 is the cause of failure 603 in the database item, the company selected in the responsibility determination selection field 1103 is in the responsibility location 604 of the database item, and the company information and user information are entered from the user's login information. 605 and the database item input person (user) 606, respectively.

  In FIG. 9, the failure record management apparatus 100 reads the failure occurrence system 404 and the failure cause 407 from the failure information database 101, and displays “Financial Accounting System” and “Middleware Failure” in the system summary display column 1101 of the responsibility determination dialog 1100, respectively. indicate. In the responsibility judgment trend number column, the number of cases for each responsibility location 604 is displayed from the responsibility judgment database 103 in the data in which the failure occurrence system 602 is recorded as “financial accounting system” and the cause of failure 602 is recorded as “middleware failure”. ing. FIG. 9 shows an example in which the responsible location is 10 data registered as A company, 5 data is registered as B company, and 1 data is registered as C company.

  In step 306, the failure record management apparatus 100 displays a responsibility determination confirmation dialog 1200 for the user at the responsibility location 604 in the responsibility determination database 103. The system summary display column 1201 displays the failure occurrence system 602 and the failure cause 603 from the responsibility determination database 103.

The responsibility judgment trend display column 1202 extracts the same fault information from the fault occurrence system 602 and fault cause 603 in the responsibility judgment database 103, and to which company the responsible location 604 is set. The number of cases is displayed. The responsibility determination selection field 1203 displays the responsibility location 604 of the responsibility determination database 103. What is responsibility judgment tendency?
As described above, the responsibility determination is not uniquely determined, and the responsibility location changes depending on the situation. Therefore, it indicates the tendency of the responsibility determination in the past in the similar failure.

  If there is no problem with the contents, the user presses OK 1204. If it is determined that there is a problem, NG 1205 is pressed. The OK / NG information is recorded in the responsibility determination confirmation 607 of the responsibility determination database 103. If OK, the process is completed. In the case of NG, the process proceeds to step 304 and the fault occurrence responsibility is input again.

101: Failure information database, 102: Response situation database, 103: Responsibility determination database, 104: Failure information processing unit, 105: Response status processing unit, 106: Responsibility determination processing unit

Claims (5)

The failure response to one failure is divided into a plurality of steps, and the start date and time information started for each step, the end date and time information that ended the failure response, the information in charge of the next step, and the input person information of this step, Correspondence situation database that stores process information as one record;
When new process information is input, the input person information of the input process information is compared with the person in charge of the next process in the correspondence status database to identify first process information that matches, The end date / time information of one process information is extracted, the start date / time of the input process information is extracted, and the end date / time information of the first process information and the start date / time information of the input process information are In comparison, when the start date and time information of the input process information is later than the end date and time information of the first process information, a response status processing unit that displays a warning, Failure record management device. The failure record management apparatus according to claim 1,
The response status processing unit further includes:
When the process information is newly input, the end date / time information of the input process information is extracted, and the person in charge of the next process of the input process information is compared with the input person information. The second process information is identified, the start date / time information of the second process information is extracted, and the start date / time information of the second process information is later than the end date / time information of the input process information. And a response status processing unit that displays a warning in the case of a failure record management device. The failure record management device according to any one of claims 1 and 2 further includes:
A fault information database for storing the information for specifying the fault and the fault occurrence system information for specifying the system in which the fault has occurred in association with each other;
A failure record management apparatus comprising: a failure information processing unit that displays a warning when the information for identifying the failure in the failure information database is different and the same failure occurrence system information exists. The failure record management device according to claim 3,
Furthermore,
The failure information database stores a failure occurrence date and time that is an occurrence date and time of the failure in association with each other,
The failure information processing unit
A failure record management apparatus, wherein a warning is displayed when a failure occurrence date and time input by the input person is within 24 hours before and after the failure occurrence date and time in the failure information database. The failure response to one failure is divided into a plurality of steps, and the start date and time information started for each step, the end date and time information that ended the failure response, the information in charge of the next step, and the input person information of this step, Storing the process information as one record in the correspondence status database;
When new process information is input, the input person information of the input process information is compared with the person in charge of the next process in the correspondence status database to identify first process information that matches, The end date / time information of one process information is extracted, the start date / time of the input process information is extracted, and the end date / time information of the first process information and the start date / time information of the input process information are And a step of displaying a warning when the start date / time information of the input process information is later than the end date / time information of the first process information. Management method.

Images