Chapter 3 Textual Databases within the Product Development Process
3.2 Some Textual Databases within the PDP
3.2.3 Problem Response System Database (PRS)
The Problem Response system was established to track, mostly design-related problems in the different phases of the PDP and provide viable solutions to them. At the company at which it was implemented, it was available online, with several levels of access.
The objectives of setting up the PRS was threefold:
o To track problems in the different phases of the PDP
o To enhace communication between design and implementation teams situated in different geographical locations
o To enable learning from past experiece and facilitate effective preventive action with a knowledge base
Since its introduction, approximately 150 records are collected monthly. The database that was provided had about 1200 records.
3.2.3.1 Data Collection Process
Figure 3.2 shows the steps involved within the PRS. Basically, four groups of users log into the system. They are the designers, project leaders, problem solvers and the quality coaches. When a designer encounters a new problem, he logs into the system to look for a solution to his problem. If the solution to a similar problem exists, he would attempt it. Otherwise he creates a new problem record. As soon as a new problem is entered, the system automatically notifies the Project Leader, via e-mail, who would then assess the problem.
Figure 3.2: Process of Problem Response System
Depending on the problem type and content, the project leader appropriately assigns a solver to the problem who would need to work towards a solution in a given time which depends on the complexity of the problem. Once a solution is found, it will be assessed by the Quality Department. If there is a need to take preventive action, the Quality Department will do so after which they will close the problem. In this manner, a Problem Response System database is created.
3.2.3.2 Database Composition
This is a mixed format database with about 40 columns of data. A short description of some of the more important fields of the database is provided in the table below. Some of the entries into the data columns in the PRS database are modified with time, depending on the action taken. (e.g. the Defects Gravity). For example, initially when the problem is reported and no action has been taken, the defects gravity value would be high. However, after some action is taken, depending on the type of solution, this value would change appropriately. A description of the important fields of the database is provided in Table 3.5 below.
PRS
Designer (problem originator)
Project Leader
Quality Coaches
New Assigned
Solved Closed
8
2 1
7
6
5 4
3
Problem Solver
Table 3.5: Description of important fields of the PRS database
No. Variable Description Format
1 Product details
Includes information like product family, values for important features (e.g screen size, speed)
Fixed discrete 2 Problem
information
Includes information like
o which site the problem originated from, o which field does the problem belong to
(electrical, mechanical),
o which part of the equipment is affected
Fixed discrete 3 Defects
gravity
Reflects the severity the problem Fixed discrete 4 Effect on
FCR/FOR
A guess as to whether the problem could affect the Field Call Rate/Fall-off rate
Fixed discrete 5 Problem
Description
A fairly detailed description of the problem at
hand Free text
6 Problem Solution
The solution to the problem
Free text 7 Problem
Cause
Outlines the major reasons for the failure
Free text 8 Condition The condition under which the problem is
observed Free text
9 Input
Information
Who keyed the information and when was it done
Fixed discrete 10 Comments Any additional remarks that might be useful Free text 11 Category Which category the problem falls into Fixed
discrete
Table 3.6 shows an extract of the textual components of the PRS database.
Table 3.6: Extract of textual information in the PRS database
Description
Symptons:TV cannot tune into PAL-xxchannels (in factory transmission & TV patten gen.), no picture or snowy picture.
Description: xx byte in the Service Mode is wrong after TV power-on.Present wrong code is xx (which is UOC ROM default for xxs tuner if UOC is unable to read from NVM IC). Correct code which is stored in xxIC is y (designated for Tuner).
Comments
The chassis is an old chassis with the purpose to test the reliability of the xx. The objective is to check for any reliability failure in the xx. As there are no failure, the objective is met. The stress will have to be conducted on a full set(x y PCB) with the voice control panel.
Cause Xx "Hi"IC having EExx was corrupted when power on/off.This pull the xC bus to low and data cannot be properly read from xx.
Solution
xx need a reset during power on/off as recommend by supplier after investigation. Reset circuit xx and yy are implement and re- run of stress test is positive.
3.2.3.3 Quality of Database
At the moment PRS is mainly used as a problem tracking system and to coordinate the communication in problem solving between design teams that are geographically located at various places. The data is not always complete as it is not compulsory to enter every record field. About 20% of the records are only partially filled or contain contents that are not very useful. This was found by manually assessing the text fields and filtering those descriptions with little/no meaningful content. It was also found that the information filled in by the engineers, especially for the description field, are of different levels of granularity. Some provided detailed information about the problem whilst others keyed in only a limited amount of information and they preferred to discuss the problem face-to-face or over the phone if a counterpart is located elsewhere. However, in general the information provided in the records was found to be quite valuable especially since the likelihood of a solution increases with better quality input.
3.2.3.4 Potential Use of Data Mining
Whenever the designer faces a problem, he would search for a similar record in the database. However this search is not an easy one. A keyword seach would end up bringing up a large set of records since the records can be quite lengthy and as such they usually contain words that repeat across documents. Sub-setting the search based on category would scale down the returned records to a certain extent. However, it is very common for the entries in the ‘category’ column to have the same input. In the database studied, about 70% of the problems belonged to the ‘design’ category. Hence this pre-defined category settings do not help much. Therefore there is a need to accurately return ranked records that might exhibit similar problems and causes. Under these circumstances, clustering might be a possible tool that could be employed.
Records could be initially placed into groups using a clustering algorithm. Then, as a new problem arises, groups of records that exhibit similar problems could be returned.