JP2007072522A - Quality improvement support system, and control method and control program therefor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a quality improvement support technique contributing to effective quality improving activity, which can specify, based on accumulated trouble information, a weak point of a related department and also present an instruction for countermeasure to the weak point. <P>SOLUTION: The quality improvement support system comprises a trouble phenomenon database containing at least data of trouble causes for individual trouble phenomena. The system calculates a risk point showing the degree of trouble improvement emergency for each trouble cause in the trouble phenomenon database (S16 and S19). The system then determines a trouble cause whose risk point exceeds a predetermined threshold as a weak point (S17 and S20). The system transmits an instruction for improvement measure to the trouble cause that is determined as the weak point to the related department (S18 and S21). <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a quality improvement support system that provides quality improvement support based on accumulated product defect information.

  In order to provide products with superior quality, it is essential to carry out quality improvement activities, such as collecting and analyzing information on defects that have occurred and analyzing them to improve manufacturing processes. In recent years, failure information is accumulated and analyzed using computer technology.

  JP 2002-334130 A (Patent Document 1) and JP 2002-358121 A (Patent Document 2) describe a malfunction phenomenon received from a market store and an inspection at a manufacturing factory regarding a manufacturing process of an automobile or the like. A quality improvement support system that compares the results is disclosed. These aim to quickly identify the cause of the occurrence of the malfunction and reflect it in the manufacturing process.

  Japanese Patent Laid-Open No. 2002-366689 (Patent Document 3) specifies the cause of a failure based on a failure phenomenon received from a dealer and an inspection result in a manufacturing factory, and measures and measures for the specified cause Is disclosed as a quality information system that can be referred to by the dealer. This is intended to enable a dealer to take a quick and accurate measure against a product in which a defect has occurred.

JP 2002-334130 A JP 2002-358121 A Japanese Patent Laid-Open No. 2002-366689

  However, the systems disclosed in each of the above-mentioned documents are limited to providing data for searching for the cause of the failure, and the system itself does not identify the cause of the failure.

  Furthermore, in recent years, it is not sufficient as a countermeasure for defects to identify the physical cause of each failure phenomenon and reflect it in the manufacturing process. Other products are based on the cause of the failure phenomenon. It is required to connect to company-wide quality improvement activities (including training of workers, accurate instructions to suppliers, etc.) to prevent the occurrence of defects. Therefore, the quality improvement support system is not limited to the output of statistical processing of defect phenomena, but realizes processing that can present weak points in manufacturing processes or departments from a company-wide perspective based on accumulated defect information. Is expected.

  The present invention provides a quality improvement support system that can identify weak points of related departments based on accumulated defect information and present countermeasure instructions for the weak points, thereby contributing to effective quality improvement activities. The purpose is to do.

  One aspect of the present invention relates to a quality improvement support system that includes a failure phenomenon database including at least failure cause data for each failure phenomenon, and that supports product quality improvement based on the failure phenomenon database. A calculation means for calculating a risk point indicating the degree of urgency of improvement of the defect for each cause of failure, a determination means for determining the cause of the defect that the risk point exceeds a predetermined threshold as a weak point, and a defect determined as the weak point And a transmission means for transmitting an improvement countermeasure instruction for the cause to the related department.

  According to this configuration, the weak point related to the cause of the defect is specified, and an improvement countermeasure instruction for the cause of the defect determined to be the weak point is transmitted to the related department. For this reason, the related departments can quickly take measures in accordance with the improvement countermeasure instructions, which can lead to the prevention of the subsequent occurrence of defects.

  According to a preferred embodiment of the present invention, the information processing apparatus further comprises a related department database including address information data for each related department, and the transmission means applies the improvement measures to all the related departments registered in the related department database. It is preferable to send the instructions.

  According to this configuration, since the improvement countermeasure instructions are sent to all the related departments, each department can share and recognize the weak points, and the awareness of all departments related to the product can be raised.

  According to a preferred embodiment of the present invention, the defect phenomenon database further includes related part data for each defect phenomenon, and a related department database including data on responsible parts and address information for each related department; And further comprising a discriminating means for discriminating the related department of each fault phenomenon by searching for the related department in which the related parts of the individual fault phenomena are described as the responsible parts in the related department database. Preferably, the determination unit performs each process for each related department registered in the related department database.

  According to this configuration, it is possible to send an appropriate improvement measure instruction to the problem that each related department has.

  According to a preferred embodiment of the present invention, it is preferable that the calculation means calculates the risk point based on at least one of the number of occurrences of a malfunction phenomenon, a defect rate, and a discovery location.

  According to this configuration, it is possible to calculate a risk point in accordance with the urgency of improvement of an actual defect, thereby improving the weak point determination accuracy.

  According to a preferred embodiment of the present invention, the image processing apparatus further includes an importance database that defines an importance level for an attribute of the defect phenomenon, and the calculation unit refers to the importance database and corresponds to the attribute of each defect phenomenon. It is preferable to weight the risk points based on importance.

  According to this configuration, it is possible to add weights to attributes having different degrees of influence on the improvement urgency level of defects, thereby improving the weakness determination accuracy.

  According to a preferred embodiment of the present invention, the defect phenomenon attribute is at least one of a quality rank representing a product quality attribute, a multiplicity representing the occurrence frequency of the defect phenomenon, and a place where the defect phenomenon occurs. It is preferable to include any of them.

  According to this configuration, it is possible to add a weight to an attribute having a high degree of influence on the improvement urgency level of the defect, thereby improving the weakness determination accuracy.

  According to a preferred embodiment of the present invention, the cause of failure preferably includes a system cause.

  According to this configuration, it is clear not the physical cause or spillage of the failure identified from each failure phenomenon, but the reason why the cause occurred systematically and why it leaked systematically. Therefore, it is possible to prevent the occurrence of system problems and the outflow.

  According to a preferred embodiment of the present invention, it is preferable that a failure cause database for defining a cause of failure is further provided, and the failure cause database has a hierarchical structure corresponding to a type of failure cause.

  According to this configuration, it is possible to determine the weak point according to the hierarchical level of the cause of the failure, and it is possible to send an improvement measure instruction having flexible and appropriate contents according to the situation.

  According to a preferred embodiment of the present invention, there is provided a receiving means for receiving a defect report serving as registration source data of the defect cause database, wherein the cause of the defect is described in free format text for one defect phenomenon; It is preferable to further include a specifying unit that performs text mining on the text included in the received failure report and specifies a failure cause in the failure cause database based on the result.

  According to this configuration, it is possible to reduce the labor required for creating a malfunction report for each terminal user.

  Another aspect of the present invention relates to a control method for a quality improvement support system that includes a failure phenomenon database including at least failure cause data for each failure phenomenon, and that supports product quality improvement based on the failure phenomenon database. A calculation step for calculating a risk point indicating a degree of improvement urgency of a failure for each failure cause in the failure phenomenon database, a determination step for determining a failure cause in which the risk point exceeds a predetermined threshold as a weak point, and the weak point And a transmission step of transmitting an improvement countermeasure instruction for the determined cause of the defect to the related department.

  According to this configuration, the weak point related to the cause of the defect is specified, and an improvement countermeasure instruction for the cause of the defect determined to be the weak point is transmitted to the related department. For this reason, the related departments can quickly take measures in accordance with the improvement countermeasure instructions, which can lead to the prevention of the subsequent occurrence of defects.

  Still another aspect of the present invention includes a defect phenomenon database including at least defect cause data for each defect phenomenon, and control executed by a quality improvement support system that supports product quality improvement based on the defect phenomenon database. According to the program, a code for calculating a risk point indicating the degree of urgency of improvement of the defect for each defect cause in the defect phenomenon database, and for determining the cause of the defect that the risk point exceeds a predetermined threshold as a weak point And a code for transmitting an improvement countermeasure instruction for the cause of the defect determined as the weak point to a related department.

  According to this configuration, the weak point related to the cause of the defect is specified, and an improvement countermeasure instruction for the cause of the defect determined to be the weak point is transmitted to the related department. For this reason, the related departments can quickly take measures in accordance with the improvement countermeasure instructions, which can lead to the prevention of the subsequent occurrence of defects.

  According to the present invention, based on accumulated defect information, it is possible to identify weak points of related departments and present countermeasure instructions for the weak points, thereby improving quality improvement support technology that contributes to effective quality improvement activities Can be provided.

  DESCRIPTION OF EMBODIMENTS Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the drawings. In addition, this invention is not limited to the following embodiment, It shows only the specific example advantageous for implementation of this invention. In addition, not all combinations of features described in the following embodiments are indispensable as means for solving the problems of the present invention. In the following, an automobile product will be described as an example, but the present invention is not limited to an automobile.

<Overall system configuration>
FIG. 1 is an overall configuration diagram of a network system to which a quality improvement support system according to the present embodiment is applied.

  Reference numeral 10 denotes a site of an automobile manufacturer, and reference numerals 20, 30, and 40 denote sites of suppliers A, B, and C, which provide automobile parts, and are connected to each other via the Internet 50. Of course, in the case where their own manufacturing factories exist at different bases, they can be connected to each other via the Internet 50 as well.

  In the company site 10, 16 is a gateway that is interposed between the backbone LAN 60 and the Internet 50 and allows the company site 10 to communicate with the Internet 50. Various LANs within the company are connected to the backbone LAN 60, and each LAN connected thereto can communicate with the Internet 50 and other LANs.

  Reference numeral 111 denotes a management site to which the quality improvement support system of the present invention is applied. In the present embodiment, the management site 111 also serves as an Internet service provider that provides Internet connection services to each department site in the company.

  In the management site 111, reference numeral 11 denotes a Web server, which provides a service that allows client terminals of each department to access a Web site on the Internet 50. A mail server 12 provides an e-mail transmission / reception service. Reference numeral 13 denotes a DNS server, which provides a service for executing name resolution for specifying an IP address from a domain name. A quality management server 14 controls the quality improvement support system, accumulates and analyzes product defect information, and provides a quality improvement support service.

  In addition to this, the management site 111 includes a failure phenomenon database (DB) 151, a failure cause DB 152, a related department DB 153, an importance DB 154, a risk point calculation DB 155, a threshold value DB 156, and an improvement instruction content DB 157. These DBs will be described later.

  Reference numerals 112, 113, and 114 denote an S department site, a T department site, and a U department site connected to the backbone LAN 60, respectively. In the S department site 112, 171 is a router for the S department site 112 to communicate with an external network using the IP protocol, and 172 is a personal computer (PC) as a client terminal having a Web browser function. The T department site 113 has the same configuration as the S department site 112 and includes a router 181 and a PC 182. The U department site 114 has the same configuration as the S department site 112 and includes a router 191 and a PC 192.

  On the other hand, 20, 30 and 40 are the sites of suppliers A, B and C which supply automobile parts and the like to the company, respectively. Reference numerals 21, 31, and 41 are gateways connected to the Internet 50 and functioning as IP routers. 22, 32, and 42 are DNS servers that provide services for executing name resolution that identifies an IP address from a domain name. Reference numerals 23, 33, and 43 denote mail servers that provide electronic mail transmission / reception services. Reference numerals 24, 34, and 44 denote Web servers that provide services that enable access to Web sites on the Internet 50. Reference numerals 25, 35, and 45 denote PCs that are client terminals each having a Web browsing function.

  In the system configured as described above, the PCs 172, 182, 192, 25, 35, 45 in each department site 112, 113, 114 and each supplier site 20, 30, 40 are respectively connected to the quality management server 14. A defect report describing details of the found defects can be sent. The quality management server 14 accumulates the content of the received defect report in the defect phenomenon DB 151.

<Hardware configuration of quality management server 14>
FIG. 2 is a diagram illustrating a hardware configuration of the quality management server 14.

  The CPU 141 is a controller that controls the entire apparatus of the quality management server 14. A RAM 142 is a system work memory for the CPU 141 to operate. The ROM 143 stores a boot program and fixed data. The HDD 143 is a hard disk drive, and stores software for realizing a quality improvement support function including an operating system (OS). A network interface (I / F) 144 is connected to the LAN and inputs and outputs information. The keyboard controller 145 connects the keyboard 145a and transmits an interrupt signal corresponding to the input of the keyboard 145a to the CPU 141. The mouse controller 146 connects the mouse 146a and transmits an interrupt signal corresponding to the input of the mouse 146a to the CPU 141. The VRAM 147 is a memory for developing image data to be displayed. The image data is expanded on the VRAM 147 so that the CRT 147a, which is an example of a display device, can display the image data.

<Software configuration related to quality improvement support function>
FIG. 3 is a diagram conceptually illustrating a software configuration related to the quality support function.

  Reference numeral 301 denotes browser software on the PCs 172, 182, 192, 25, 35, and 45 in each department site 112, 113, and 114 and each supplier site 20, 30, and 40. It has a function of receiving an HTML file and displaying it, and a function of receiving an HTML file related to a countermeasure instruction message from the management site 10 and displaying it.

  The following is a software configuration of the quality management server 14 in the management site 111.

  The HTTP communication unit 302 transfers the HTML file between the quality control server 14 and the PCs 172, 182, 192, 25, 35, 45 in the respective department sites 112, 113, 114, and the supplier sites 20, 30, 40. Is a module that performs this based on HTTP. Also, the HTTP communication unit 302 transfers various information input on the browser 301 to the quality management server 14 based on HTTP.

  The file transmission unit 303 is a module that realizes a function of transferring an HTML file to be transmitted to the browser 301 to the HTTP communication unit 302.

  The CGI interface 304 activates a predetermined CGI when there is a request via the Common Gateway Interface (CGI) among the responses related to the HTML file transmitted from the browser 301, and an HTML file or predetermined information generated by the CGI. Transfer the file to the browser 301.

  The file management unit 305 manages an HTML file for distributing information to the browser 301. The HTML file to be managed includes a UI file 306 that is various image files used as a user interface (UI).

  The authentication CGI application 307 performs authentication processing based on the user ID and device ID of the user who has logged into the browser 301. Specifically, the authentication CGI application 307 receives a user ID and a device ID of a PC from the browser 301, and performs an authentication process with reference to an authentication DB (not shown).

  The failure report CGI application 308 transmits a failure report format (HTML file) to the browser 301 in response to an instruction from the logged-in user.

  When the countermeasure instruction CGI application 309 receives a defect report, the countermeasure instruction CGI application 309 accumulates the contents of the report in the defect phenomenon DB 151 and executes quality improvement support processing as described later with reference to each DB.

<Processing related to defect reports>
FIG. 4 is a flowchart showing processing when the quality management server 14 receives a defect report form transmission request from the browser 301.

  First, in step S1, the authentication CGI application 307 transmits a login page to the browser 301 to prompt input of a user ID and a device ID. In step S2, the user ID and device ID transmitted from the browser 301 are received.

  Next, in step S3, the authentication CGI application 307 refers to an authentication DB (not shown) and determines whether a service can be provided for the received user ID and device ID. Specifically, the authentication DB stores, for example, a user name, a password, and a device ID (manufacturing number, IP address, etc.) of a PC that can be used by a login user. Here, when the received combination of the user ID and the device ID is not detected from the authentication DB, the process proceeds to step S4, a login rejection is notified, and the process ends.

  On the other hand, if the received combination of the user ID and the device ID is approved and the service can be provided, the process proceeds to step S5, where the defect report CGI application 308 transmits the defect report form to the browser 301 and ends the process.

  An example of the defect report form displayed on the browser 301 is shown in FIG. In the example shown in the figure, the items describing the contents of the defect include title, date of occurrence, place of discovery, quality rank, frequent occurrence, failure status, treatment (taken for that status), related parts, failure cause, etc. It is prepared. Among these, the PC operator can input text in the input field of each item. Of course, not only letting you write text as shown, but for example, for items that have a fixed description such as quality rank, multiple occurrence, and related parts, a list of choices is presented in advance, and you can select it with a mouse click. You may do it. For example, the “quality rank” indicates an attribute of product quality, and is described by ranking A, B, and C according to product safety, merchantability, and the like. Therefore, any one of A, B, and C may be presented as an option list so that it can be selected from the list. Further, “multiple” is an index indicating the frequency of occurrence of a malfunction phenomenon, and for example, it can be selected as “present” or “not present”.

  Further, in the present embodiment, the description of the cause of the defect is entered in the “defect cause I” field in a free format so that the details can be investigated, and “defect cause II” is used for easy classification. The corresponding item is checked from the choices for the cause of failure displayed in the column. In the figure, the failure cause choices displayed in the “failure cause II” column correspond to a data structure example of the failure cause DB 152 described later.

  The PC operator can input the above defect report and return the defect report to the quality management server 14 by clicking the “Send” button at the bottom of the form. It is also possible to delete the currently input content by clicking the “clear” button prepared next to the “send” button.

  Although the processing related to the defect report is generally as described above, the input of the defect report may be performed with a plurality of departments involved. For example, when the defect report of the example of FIG. 5 is created at the company A site 20 of FIG. 1, items other than the cause I and II of the defect are entered in the department where the defect occurs in the company A. It is input in the responsible department within the company.

  As processing at that time, first, a defect report form transmission request is issued to the quality management server 14 from the client PC in the defect occurrence department. In response to this, the quality management server 14 transmits a defect report form to the client PC in the defect occurrence department by the above-described processing. This client PC inputs items other than the causes of failure I and II and transmits them to the quality management server 14. The quality management server 14 temporarily stores the received data in the HDD 143 or the like.

  Thereafter, when the client PC in the responsible department issues a defect report form transmission request to the quality management server 14, the quality management server 14 recognizes that this is a request from the same company A and stores the data stored in the HDD 143. Is sent to the client PC in the responsible department. This client PC inputs an unfilled item, that is, an item of defect cause I and II, and transmits this to the quality management server 14. In this way, it is possible to complete a defect report by involving a plurality of departments.

<Example of database structure>
An example of the data structure of the defect phenomenon DB 151 is shown in FIG. This failure phenomenon DB 151 is constructed based on the failure report sent from each PC by the above-described processing, and failure analysis is performed based on the failure report, and countermeasures are advanced. As shown in the figure, the failure phenomenon DB 151 has data fields such as a report number, failure state, failure cause, discovery location, quality rank, frequent occurrence, and related parts. When the failure report is received, the data in the corresponding column of the failure report shown in FIG. 5 is copied to each data field.

  Further, in the present embodiment, two data fields “defect cause I” and “defect cause II” are provided as data fields describing the cause of the defect in correspondence with the format of the defect report shown in FIG. Therefore, the text described in the “defect cause I” column of the defect report shown in FIG. 5 is copied in the “defect cause I” data field, and “defect cause II” is displayed in the “defect cause I” data field. A number for identifying the option selected in the column (defined in the failure cause DB 152 as described later) is described.

  An example of the data structure of the failure cause DB 152 is shown in FIG. The failure cause DB 152 in the present embodiment is characterized in that it describes not so-called processes causing the failure but so-called system causes such as an organization and a plan. As shown in the figure, this data structure has a hierarchical structure according to the type of cause of failure, such as a large item, a medium item, and a small item. The 3-digit numerical value in parentheses represents the identification code of each data. Here, for example, a large item is specified by hundreds, a middle item is specified by ten, and a small item is specified by one.

  An example of the data structure of the related department DB 153 is shown in FIG. The related department DB 153 is like an address book, and describes the responsible parts and address information (email address, URL, etc.) of each department including the supplier and the internal department.

  An example of the data structure of the importance DB 154 is shown in FIG. This defines the importance corresponding to the attribute of the defect phenomenon in order to efficiently carry out quality improvement activities. Here, the importance is defined as A, B, C,. For example, in the example shown in the figure, a defect phenomenon having attributes of quality rank “A”, discovery place “external process”, and frequent occurrence “none” is ranked with importance A. In addition, defect phenomena having attributes of quality rank “B”, discovery place “finished product”, and frequent occurrence “present” are ranked with importance B, quality rank “C”, discovery place “in-house process”, frequent occurrence A malfunction phenomenon having the attribute of “nothing” is ranked in importance C. As described above, in this embodiment, the importance is defined according to the combination of the quality rank, the discovery location, and the frequent occurrence, which are the attributes of the defect phenomenon. However, the definition of the importance is not limited to this, and it is sufficient that the importance is defined by at least one of the attributes such as the quality rank, the discovery place, and the multiplicity.

  An example of the data structure of the risk point calculation DB 155 is shown in FIG. The risk point is an index indicating the degree of urgency for improvement for a certain defect. It can be said that the greater the risk point, the higher the urgency of improvement for the defect. As shown in the figure, the risk point calculation DB 155 in the present embodiment is configured to include a number of points table 155a, a defect rate point table 155b, an importance point table 155c, and an occurrence point table 155d as sub-databases. . The number of points table 155a describes the correspondence between the number of occurrences of a certain defect and the number of points. The defect rate point table 155b describes the correspondence between the defect rate and the defect rate point in a certain defect set. Here, ppm (number of defective products when one million units are manufactured) was used as the unit of defective rate. The importance point table 155c describes the correspondence between the importance ratios (the ratios of A, B, and C) and importance points in a certain defect set. The occurrence location point table 155d describes the correspondence between occurrence location ratios and occurrence location points in a certain defect set.

  An example of the data structure of the threshold DB 156 is shown in FIG. This describes the threshold for risk points for each supplier and each internal department. In the example shown in the figure, the threshold values for each supplier and each internal department are all set to the same 8.00, but may be set to different values as a matter of course. The threshold value DB 156 also includes risk point threshold values for items (for all suppliers / for all departments). This threshold value DB 156 is used in weak point determination processing described later.

  An example of the data structure of the improvement instruction content DB 157 is shown in FIG. This is a description of countermeasure instruction content for each cause of failure defined in the failure cause DB 152. This improvement instruction content DB 157 is used in countermeasure instruction processing described later.

<Content of quality improvement support processing>
Hereinafter, quality improvement support processing by the quality management server 14 will be described. This process is started, for example, when the quality management server 14 receives a defect report.

  FIG. 6 is a flowchart showing quality improvement support processing by the quality management server 14.

  First, in step S11, the countermeasure instruction CGI application 309 additionally registers the content of the received defect report in the defect phenomenon DB 151. As shown in FIG. 7, the data of the corresponding item of the received defect report is additionally written in each data field of the defect phenomenon DB 151.

  Next, in step S12, the countermeasure instruction CGI application 309 performs related department determination processing. This is the process of identifying the internal departments and suppliers involved in each failure phenomenon. Specifically, the countermeasure instruction CGI application 309 refers to the “related parts” data field of each malfunction phenomenon, and searches for the internal departments and suppliers in which the related parts are described as responsible parts in the related department DB 153. For example, in the case of the failure phenomenon No. 001 in the failure phenomenon DB 151 shown in FIG. 7, the related part is “A part”. Here, referring to the related department DB 153 of FIG. 9, it is the supplier A that “A part” is described in the “in charge part” data field. In this way, the department related to each malfunction phenomenon is specified.

  Next, in step S13, the countermeasure instruction CGI application 309 performs importance level determination processing for determining the importance level of each malfunction phenomenon. Specifically, the countermeasure instruction CGI application 309 refers to the importance DB 154 to determine the importance of each malfunction phenomenon. For example, in the case of the failure phenomenon No. 001 in the failure phenomenon DB 151 shown in FIG. 7, it has attributes of quality rank “B”, discovery place “finished product”, and multiple occurrence “present”. Here, referring to the importance DB 154 of FIG. 10, it is determined that the failure phenomenon of No. 001 corresponds to the importance A.

  Next, in step S14, the countermeasure instruction CGI application 309 performs countermeasure instruction type selection processing. In the present embodiment, it is possible to select either a countermeasure instruction by related department or a countermeasure instruction by cause item. Specifically, for example, the countermeasure instruction CGI application 309 causes the CRT 147a to display a UI for allowing the operator of the quality management server 14 to select whether the countermeasure instruction for each related department or the countermeasure instruction for each cause item is to be performed. A display example of this UI is shown in FIG. In the example shown in the figure, a defect list generated based on the defect phenomenon DB 151 is displayed as reference information, and a “total by cause item” button and a “total by related department” button are displayed. If the “summary by cause item” button is clicked with the mouse, the process proceeds to step S16. If the “summary by related department” button is clicked with the mouse, the process proceeds to step S19.

  In step S16, the countermeasure instruction CGI application 309 performs defect cause aggregation processing. This is a process of calculating risk points for each cause item of the defect.

An example of calculating this risk point is shown in FIG. For example, in the case of “FMEA” which is one cause item of the defect, as a result of referring to the risk point calculation DB 155, as shown in FIG. 15, the number of cases is 2.00, the defect rate point is 2.00, the importance point is 2.00. Suppose the location point is 1.25. Risk points are calculated by multiplying each of these points. That is, the risk points for FMEA are
2.00 × 2.00 × 2.00 × 1.25 = 10.0
It becomes. Thus, the multiplication result of each point becomes a risk point. Here, since the importance point is a point defined based on the importance of each defect phenomenon, this risk point is weighted by the importance point based on the importance according to the attribute of the defect phenomenon. It can be said that there is.

  As described above, a risk point is calculated for each cause item of the defect.

  Next, in step S17, the countermeasure instruction CGI application 309 performs cause item weak point determination processing. Specifically, the risk point for each cause item of the defect calculated in step S16 is compared with the risk point threshold value for each item (for all suppliers / all department development) in the threshold value DB 156. Cause items exceeding the threshold are determined as weak points.

  Thereafter, the countermeasure instruction CGI application 309 displays the results of the failure cause aggregation process and the weakness determination process on the CRT 147a of the quality management server 14 in the UI. FIG. 16 shows a display example of the UI of the failure cause totaling process and the weakness determination process result displayed in step S17. In this UI, a bar graph 1501 for each cause item representing the result of the trouble cause aggregation process in step S16 is displayed. For example, stars 1502 to 1504 are displayed on the bar graph of the cause item determined to be a weak point in step S17. This allows the operator to see at a glance what items are weak points.

  In the present embodiment, the operator can select a hierarchy of cause items to be processed in steps S16 and S17. For example, the figure includes a combo box 1505 for selecting a hierarchy of cause items, and an operator can select any one of a small item, a medium item, and a large item using the mouse 146a. it can. In the example shown in the figure, the small item is selected. When the selection is changed, steps S16 and S17 are preferably executed for the item of the selected hierarchy.

  Reference numeral 1506 denotes an “improvement countermeasure instruction” button. When this button is clicked with the mouse, an improvement countermeasure request UI as shown in FIG. 17 is displayed on the CRT 147a. Here, cause items determined to be weak points on the system and improvement instruction contents corresponding to the respective cause items obtained by referring to the improvement instruction content DB 157 as shown in FIG. 13 are displayed. Reference numerals 1701 and 1702 denote “send mail” buttons for sending the corresponding improvement instruction contents by e-mail. When the “mail transmission” button 1701 or 1702 is clicked with a mouse, the countermeasure instruction CGI application 309 executes countermeasure instruction processing for each cause item in step S18. For example, when the “send mail” button 1701 is clicked with the mouse, the countermeasure instruction CGI application 309 displays the contents of the improvement instruction as shown in FIG. 18 for all suppliers / all departments registered in the related department DB 153. The e-mail included in is broadcast.

  On the other hand, in step S19, the countermeasure instruction CGI application 309 performs a process of calculating risk points for each related department as a failure cause aggregation process. In step S16 described above, risk points for each cause item are calculated for all suppliers / departments, but in this step S19, risk points for each cause item are calculated for each supplier / department. The calculation method itself may be as shown in FIG.

  Next, in step S20, the countermeasure instruction CGI application 309 performs weak point determination processing for each related department. Specifically, the risk point for each cause item calculated for each supplier / department in step S19 is compared with the risk point threshold of the corresponding supplier / department in the threshold DB 156, and the risk point exceeds this threshold. The cause item is determined as a weak point.

  Thereafter, the countermeasure instruction CGI application 309 displays the results of the failure cause aggregation process and the weakness determination process on the CRT 147a of the quality management server 14 in the UI. FIG. 19 shows a display example of the UI of the failure cause totaling process and the weak point determination process result displayed in step S20. On this UI, a bar graph 1901 for each cause item representing the result of the trouble cause aggregation process in step S19 is displayed. Then, for example, stars 1902 to 1904 are displayed in the bar graph of the cause item determined as the weak point in step S20. This allows the operator to see at a glance what items are weak points.

  In this embodiment, the operator can select a related department to be displayed. For example, the figure includes a combo box 1905 for selecting a related department, and the operator can use the mouse 146a to select a supplier / department. In the illustrated example, supplier A is selected, and a bar graph of cause items related to the company A is displayed. Further, here, as in FIG. 16, the operator can select the hierarchy of the cause items to be processed in steps S19 and S20. For example, FIG. 19 includes a combo box 1906 for selecting a hierarchy of cause items, and the operator can select any one of a small item, a medium item, and a large item using the mouse 146a. it can. In the example shown in the figure, the small item is selected. When the selection is changed in these combo boxes 1905 and 1906, it is preferable that steps S19 and S20 are executed according to the selection contents.

  Reference numeral 1907 denotes an “improvement countermeasure instruction” button. When this button is clicked with the mouse, an improvement countermeasure request UI as shown in FIG. 20 is displayed on the CRT 147a. Here, the related department (for example, supplier A) selected as the responsible party selected in the combo box 1905 in FIG. 19, the cause item determined to be a weak point in the system, and the improvement instruction as shown in FIG. The improvement instruction content corresponding to each cause item obtained by referring to the content DB 157 is displayed. Reference numerals 2001 and 2002 denote “email transmission” buttons for transmitting the corresponding improvement instruction contents by e-mail. When the “mail transmission” button 2001 or 2002 is clicked with the mouse, the countermeasure instruction CGI application 309 executes the countermeasure instruction processing for each cause item in step S21. For example, when the “send email” button 2001 is clicked with the mouse, the countermeasure instruction CGI application 309 refers to the related department DB 153 to extract the email address of the supplier A who is responsible in this example, and sends the email address to this email address. As shown in FIG. 21, an e-mail including the content of the improvement instruction in the text is transmitted.

  The above processing has been described as being started when the quality management server 14 receives one defect report. However, it is not executed every time one is received, but may be executed when the number of additional registrations in the defect phenomenon DB 151 reaches a predetermined plural number (for example, 10), or quality control. It may be executed after waiting for an instruction from the operator of the server 14.

  As described above, according to the quality management server 14 that is the quality improvement support system in the present embodiment, it is possible to issue an improvement instruction to related departments / suppliers based on the accumulated defect information.

  In the above-described embodiment, the improvement instruction is transmitted by e-mail. However, a mechanism may be adopted in which the Web site is accessed from each site to the management site 10 and an improvement instruction message for the own site is extracted.

  Further, in the above-described embodiment, in the defect report (FIG. 5), text in free format is input in the “defect cause I” column, and the corresponding ones from the defect cause options displayed in the “defect cause II” column are displayed. An example of checking is described. However, instead of eliminating the “Cause Cause II” field, instead of introducing a process that identifies one of the trouble causes registered in the trouble cause database based on the text entered in the “Cause Cause I” field. Also good.

  For example, before performing the additional registration process of the defect phenomenon DB 151 in step S11, the quality management server 14 uses a well-known text mining or keyword for the text entered in the “problem cause database 152 using the defect cause I” field. It is possible to apply an extraction technique. By introducing such processing, it is possible to reduce the labor required for creating a malfunction report for each terminal user.

1 is an overall configuration diagram of a network system to which a quality improvement support system of the present invention is applied. It is a figure which shows the hardware constitutions of the quality management server in embodiment. It is a figure which shows notionally the software structure which concerns on the quality assistance function in embodiment. It is a flowchart which shows the process at the time of the quality management server in embodiment receiving a malfunction report form transmission request. It is a figure which shows the example of a display of the malfunction report form in embodiment. It is a flowchart which shows the quality improvement assistance process by the quality management server in embodiment. It is a figure which shows the example of a data structure of malfunction phenomenon DB in embodiment. It is a figure which shows the example of a data structure of defect cause DB in embodiment. It is a figure which shows the example of a data structure of related department DB in embodiment. It is a figure which shows the example of a data structure of importance DB in embodiment. It is a figure which shows the data structure example of DB for risk point calculation in embodiment. It is a figure which shows the example of a data structure of threshold value DB in embodiment. It is a figure which shows the example of a data structure of improvement instruction | indication content DB in embodiment. It is a figure which shows the example of a display of UI in the countermeasure instruction | indication type selection process in embodiment. It is a figure which shows the risk point calculation example in embodiment. It is a figure which shows the example of a display of UI of the weak point determination process result in embodiment. It is a figure which shows the example of a display of UI for improvement countermeasure request | requirement in embodiment. It is a figure which shows an example of the email addressed to all the related departments containing the improvement instruction | indication content in embodiment. It is a figure which shows the example of a display of UI of the weak point determination process result in embodiment. It is a figure which shows the example of a display of UI for improvement countermeasure request | requirement in embodiment. It is a figure which shows an example of the electronic mail addressed to the designation | designated relationship department containing the improvement instruction | indication content in embodiment.

Explanation of symbols

10: Company site 11: Web server 12: Mail server 13: DNS server 14: Quality management server 151 1: Defect phenomenon database (DB)
152: Problem cause DB
153: Related department DB
154: Importance DB
155: Risk point calculation DB
156: Threshold DB
157: Improvement instruction content DB
20: Supplier A company site 30: Supplier B company site 40: Supplier C company site 50: Internet

Claims (11)

A quality improvement support system comprising a defect phenomenon database including at least defect cause data for each defect phenomenon, and providing product quality improvement support based on the defect phenomenon database,
A calculation means for calculating a risk point indicating the degree of urgency of improvement of a defect for each cause of failure in the defect phenomenon database;
Determining means for determining a cause of a failure in which the risk point exceeds a predetermined threshold as a weak point;
A transmission means for transmitting an improvement measure instruction for the cause of the defect determined as the weak point to a related department;
A quality improvement support system characterized by comprising: A related department database including address information data for each related department is further provided.
The quality improvement support system according to claim 1, wherein the transmission unit transmits the improvement measure instruction to all related departments registered in the related department database. The defect phenomenon database further includes data of related parts for each defect phenomenon,
A related department database containing data on responsible parts and address information for each related department,
A discrimination means for discriminating a related department of each fault phenomenon by searching for a related department in which the related parts of the individual fault phenomenon are described as a responsible part in the related department database,
Further comprising
The quality improvement support system according to claim 1, wherein the calculation unit and the determination unit perform respective processes for each related department registered in the related department database.   The said calculation means calculates the said risk point based on at least any one of the occurrence number of defect phenomena, a defect rate, and a discovery place, The Claim 1 characterized by the above-mentioned. Quality improvement support system. It further includes an importance database that defines the importance of the defect phenomenon attributes,
The said calculation means performs weighting of the said risk point based on the importance according to the attribute of each malfunction phenomenon with reference to the said importance database. The claim 1 characterized by the above-mentioned. Quality improvement support system.   The attribute of the malfunction phenomenon includes at least one of a quality rank representing an attribute of product quality, a multiplicity representing an occurrence frequency of the malfunction phenomenon, and a place where the malfunction phenomenon occurs. 5. The quality improvement support system according to 5.   The quality improvement support system according to any one of claims 1 to 6, wherein the cause of failure includes a system cause.   The quality improvement support system according to claim 7, further comprising a failure cause database that defines a cause of the failure, wherein the failure cause database has a hierarchical structure according to a type of the failure cause. Receiving means for receiving a defect report as registration source data of the defect cause database, wherein the cause of the defect is described in free format text for one defect phenomenon;
Performing a text mining on the text included in the received failure report, and identifying means for identifying a failure cause in the failure cause database based on the result;
The quality improvement support system according to claim 1, further comprising: A control method of a quality improvement support system that provides a defect phenomenon database including at least defect cause data for each defect phenomenon, and supports product quality improvement based on the defect phenomenon database,
A calculation step for calculating a risk point indicating a degree of urgency of improvement of a defect for each cause of failure in the failure phenomenon database;
A determination step of determining a cause of a failure in which the risk point exceeds a predetermined threshold as a weak point;
A transmission step of transmitting an improvement measure instruction for the cause of the defect determined as the weak point to a related department;
A control method for a quality improvement support system, comprising: A control program that is executed by a quality improvement support system that includes a defect phenomenon database including at least defect cause data for each defect phenomenon, and that supports product quality improvement based on the defect phenomenon database,
A code for calculating a risk point indicating the degree of urgency of improvement of the defect for each cause of the defect in the defect phenomenon database;
A code for determining a cause of a failure in which the risk point exceeds a predetermined threshold as a weak point;
A code for transmitting an instruction for improvement measures to the cause of the defect determined to be the weak point, to a related department;
A control program comprising:

Images