Introduction
This chapter describes a knowledge management system that trou- bleshoots the manufacturing process in aluminum die-casting foundries in the U.K. Established in 1974, Wilson & Royston Ltd. has subsidiaries in the U.K., U.S., Spain, and Mexico. They combine their manufacturing experience with state-of-the-art technology and inte- grated CAD/CAM to provide a specialist service for pressure die-casting tools, plastic and rubber injection, compression and transfer moulds, jigs, fixtures, and press tools, plus a precision machining service.
The accumulation of past knowledge is a by-product of the normal working practice of reporting problems within a foundry, rather than by the creation of a new software maintenance action. Solutions to past problems are stored as cases, and CBR finds possible solutions when new problems occur. A significant advancement in the use of CBR for troubleshooting applications is that cases become a resource for im- proving process design by reducing the incidence of similar problems in the future.
The Problem
Two kinds of primary processes are used within aluminum die-casting:
■ Gravity die-casting, where molten metal is poured into a die, or mould. This is useful for casting relatively simple shapes when a low volume of parts is required.
■ Pressure die-casting, where molten metal is injected at high pres- sure into the die. This is the more common technique for mass- producing a large number of parts, or when more complex shapes are required.
Customers expect die-casters to produce finished or near-finished parts; so in practice foundries perform a number of secondary opera- tions in addition to die-casting. There are also several operations carried out prior to the casting stage. For this reason the term die-casting in this chapter is used in the broader sense, to mean the production of finished (or near-finished) parts from raw materials; in other words, all the stages involved in the manufacturing process (drilling, lathing, painting, etc.), not just the act of pouring molten metal or injecting it into a die.
Several problems are associated with die-casting:
■ Typically, the customer is responsible for the design of the part and often has little or no regard for the processes employed to produce it. That is, functional considerations take precedence over produc- tion considerations. In addition, the customer has aesthetic con- siderations that can sometimes place unnecessary constraints on
the die-caster. Quality expectations can also be unrealistically high due to insufficient in-depth knowledge of the processes used in die-casting.
■ Keeping track of problems can be difficult. Failures discovered at late stages of manufacture are often caused by early manufac- turing stages. Moreover, certain problems tend to reoccur less frequently than others, making it difficult to find out how a fail- ure was dealt with on a previous occasion. Experienced foundry staff tend to fix problems without needing to refer to past records, but when key staff retire or change jobs, this knowledge is lost.
■ Tracing the root causes of quality-related problems can also be dif- ficult. Foundry staff rely on experience when deciding on which paths to investigate, because looking at all the possibilities would be impractical or too time consuming.
Two paper-based systems were in use at the foundries: Process Concern Reports (PCR) and Eight Discipline (8D) reports.1 Both of these systems were used for reporting foundry problems. When a prob- lem with a part was reported, either by a customer or from within the foundry, a new PCR would be raised. The form records all the infor- mation concerning the problem, customer details, the actions to rem- edy the problem, and a list of personnel carrying out the recommended actions. The form is then circulated among the personnel named on the form, the actions are carried out, and the PCR closed once the prob- lem is solved. Once closed, the PCR is filed for later reference.
This type of system is valuable because it is a record of the foundry’s troubleshooting experience. The quantity of paper involved, however, made it impractical to search and retrieve appropriate records for problem-solving purposes.
The Knowledge Management Solution
Certain types of problems are common enough for foundry staff to know what to do without having to refer to any kind of records or doc- umentation. Less common failures are more likely to be problematic because the experience gained from fixing such a problem on a previ- ous occasion is more likely to be lost. Even if the information was recorded, finding the appropriate records when required can prove dif- ficult, especially with paper-based systems. This makes CBR an obvi- ous knowledge management methodology to use.
Very often paper-based records already exist, which make good raw material for case-based systems. It is just a question of identifying them and storing them in an accessible way. The PCR and 8D reports were used as the basis for a computer system that records problems in a case base used as a resource for troubleshooting by employing CBR techniques.
Expected Benefits
Predicting the benefits from the implementation of a knowledge man- agement system is rarely straightforward. Process improvements and intangible efficiency gains are not always easy to quantify. Thus, it is helpful to look for a quantifiable measure that may approximate ob- tainable benefits. In an aluminum foundry a reduction in the amount of scrap metal generated, mostly caused by failed castings, is one such metric. At the beginning of this project we estimated that the combined use of the systems would realize a 10 percent reduction of scrap metal. This in turn would save an estimated $150,000 a year at each foundry.
The Team
This project, called QPAC,2 was a three-year research project involv- ing the University of Wales at Aberystwyth and three aluminum diecasters, namely Kaye (Presteigne) Ltd., Burdon and Miles Ltd., and Morris Ashby Castings, all owned by Wilson & Royston. The main aims of the project were as follows:
■ Capture of information relating to foundry problems
■ Reuse of this information for troubleshooting foundry-related problems and for providing statistical information
■ Automation of Process Failure Modes and Effects Analysis (Process FMEA)
Implementation Plan
Our approach was to develop integrated software tools that can share information stored in databases. Real data had to be used to test our soft- ware. This means building tools robust enough to be tested and used in real industrial environments. To this end, prototype software tools have been delivered to our industrial collaborators during the course of the project. They have been used in each foundry over some years.
Each foundry has a network of PCs and servers. The existing sys- tems used at each of the sites were very similar. Because the aim of the project was to develop tools that could perform different tasks but share data and knowledge, we used conventional databases to store in- formation. We wanted to gather realistic data quickly. To this end, we used Delphi as our software development tool. This enabled us to de- liver prototypes quickly and gather information and feedback from our industrial partners.
The main CBR tool is the PCR system, which records foundry prob- lems and uses its database as a case-base for troubleshooting. The Statistical Process Control (SPC) system records results of SPC studies and uses CBR to predict process capability. The Process Flowchart sys- tem is used to design the complete casting process. The result of this design is a list of processes, which forms the framework for the auto- generation of Process Failure Modes Effect Analysis (FMEA).
Both the SPC and PCR systems are referenced during FMEA gener- ation. The SPC system provides useful information for finding the occurrence of certain problems. References to real PCRs are used in the FMEA so that the generic results the system generates can be com- pared with real-life problems.
System Architecture
As previously mentioned, two paper-based systems held valuable trou- bleshooting information, namely, the PCR and 8D reports. We decided to build a database system that would combine the information stored in these two reports. In order to gather as much realistic data as possi- ble, this system was implemented at the earliest possible stage, and has now replaced the paper-based systems at all three foundries. The PCR system is now on the foundries’ networks so that users can access the system from any terminal.
The automated PCR system has four main functions:
1. To hold information for PCR and 8D reports
2. To facilitate troubleshooting by employing CBR techniques
3. To provide graphical information on problems within the foundry
4. To provide a source of information for automating Process FMEA
The PCR system is a source of past cases of problems with solu- tions. Given a current PCR as input, the system looks through the list of completed PCRs for the ones that it deems to be the most similar. The solutions from the chosen past cases may then give valuable in- formation on how to solve the current problem. The CBR system uses the nearest neighbor method for retrieving cases. A schematic of the system architecture is shown in Figure 5.1.
The Process Flowchart System
One part of IS0-9000 (APQP—Advanced Product Quality Planning) requires the drawing of a flowchart that represents the sequence of steps involved in the production of a particular manufactured product.
The production of this flowchart involves a certain amount of input from the customer; so there is inevitably some faxing or emailing back and forth of prototype charts before both sides are happy with the re- sult. The flowchart is graphical in nature and employs a set of symbols to denote specific types of process.
The flowchart system produced by QPAC employs the same con- ventions as the manual system already in use at Morris Ashby’s. Flowcharts are stored in a database and can be printed graphically from within the program. The use of symbols (and optionally color) makes it easier to spot weaknesses in the process sequence (such as a run of operations with no inspection stages). (See Figure 5.2.)
The process names used by the flowchart system are the same as those employed by the PCR system. A database table specifies all the al- lowable failure modes for each process recognized by the system, while a separate maintenance system allows the user to alter the tables. Having the same names for processes and failures in all systems helps the automation of Process FMEA. The FMEA system, which is incor- porated into the process-flowchart program, takes the list of processes from the appropriate flowchart and, using the process/failure table, generates all the combinations of processes and failures required for a Process FMEA. Each line of the FMEA has a list of PCRs associated with it (for example, completed PCRs that match the process, failure, and part category). Accessing the SPC system (described next) can also generate certain values required for Process FMEA.
The SPC System
The Statistical Process Control system is a database for recording the results of SPC studies (that is, Process Capability studies and Machine Capability studies). It includes a feature for predicting process capa- bility for user-defined tolerances using CBR. Given the upper and lower tolerances (U.S.L and L.S.L), the system calculates the midpoint and applies nearest neighbor techniques to find the predicted process capability (CPK) from the best matching cases. (See Figure 5.3.) The predicted value is calculated by adapting the CPK value from the past case to fit in with the user’s new tolerances.
A user accesses the system to obtain Occurrence values for Process FMEA, again using simple CBR techniques. Occurrence is a qualita- tive integer value between 1 and 10 that indicates how often the prob- lem is likely to occur. It is a function of CPK, and is obtained from a suitable past case, using the SPC’s database as the case-base.
Case Representation
The PCR database is a case base for troubleshooting problems within the foundry. As with all the systems, a conventional database structure stores the information. The following EXPRESS description defines all the PCR and 8D information as a single entity. Where not obvious, the data types are plain text.
Case Acquisition
Each foundry had its own stock of past cases stored on paper, based on their own experiences. We decided that combining these into a sin- gle database was undesirable since each foundry manufactures differ- ent kinds of parts and uses slightly different methods and different ma- chinery. Therefore, each foundry maintains its own case base. The initial set of past cases came from paper-based PCRs and 8D reports. The representation used by the computerized system was closely based on the existing paper-based one; consequently, cases are stored virtu- ally “raw,” requiring no further processing.
Since the cases were input by the foundries themselves, much of the knowledge acquisition was automatic. However, we still needed to be able to understand the information ourselves in order to represent it in a sensible way. This requires an understanding of:
■ the terminology used,
■ the typical kinds of problems involved,
■ the interrelationships between the various bits of information, and
■ quality procedures.
Case Retrieval
The case-based troubleshooting system uses nearest neighbor retrieval to find the most appropriate cases. The CBR system also employs a parts clas- sification system that assigns numerical values for five quality attributes:
■ surface finish (for example, smoothness),
■ aesthetic appearance,
■ integrity (for example, lack of porosity),
■ cleanliness (for example, lack of swarf/flash), and
■ stability (for example, strength).
Each of the five quality attributes takes on a qualitative value, which represents the level of importance of the attribute. The part classifica- tion options give sensible default values to begin with. The user can then fine-tune the attributes to give values that are more appropriate for the current PCR. The quality attributes are then used in conjunc- tion with nearest neighbor matching to retrieve past-case PCRs. The default quality attributes are derived from a component hierarchy that orders the matched cases so that the most likely cases will be those as close as possible in the hierarchy to the problem.
The case-based system within the PCR system uses nearest neighbor matching to retrieve cases. The properties (and limitations) of nearest neighbor matching are well understood, but the system is flexible enough to allow users to configure the system so that the best possible match can be achieved with only a couple of attempts. Furthermore, since the system retrieves a list of cases instead of just one, users can judge which one is best.
Case Adaptation and Retention
Information is stored in the PCR system in a very raw state, as detailed textual descriptions that contain specific technical details such as measurements. It is considerably less difficult for users, even with limited foundry experience, to perform their own adaptation than to implement some form of automated adaptation. Automation would have required a much more complex case structure that would have been difficult for foundry personnel to use. For this reason adap- tation is not used within the troubleshooting system.
Being a database system, and a replacement for a paper-based sys- tem, cases are added to the PCR as a by-product of existing quality procedures. The process is entirely automatic, requiring no preprocessing whatsoever.
Interface Design, Testing, and Rollout
A great deal of effort went into designing the user interface for the PCR system. The Delphi software development environment made it possible to create demo interfaces in a very short amount of time that were shown to foundry personnel for review and comment. After a few trials the “tabbed notebook” style of user interface (see Figure 5.4) was adopted, as it let us display a large amount of data with more com- pactness than the earlier attempts, which used many separate forms. We adopted the same interface style at various levels within the other systems.
As previously mentioned, we delivered the systems to the foundries at various stages throughout the course of the project. In addition to the users in the foundries using the program, we were able to gather realistic data from the foundries and use this to test the systems for ourselves. Because of the way we delivered the software, it was quite natural for a great deal of feedback to come from the foundries, which in turn led to many enhancements to the system.
The case bases are unique to each site. Had the case base been global we would have had problems with some of the terminology, which is also local to each site. Although each of the case bases is now quite large, it is useful for users to be familiar with the dies that relate to them. This is because it will give users greater confidence in the sys- tem’s ability to retrieve suitable cases.
System Demonstration
The PCR system is designed to be as user-friendly as possible. For ex- ample, when users select a die number from a drop-down list, the pro- gram automatically fills in the part number as well as the customer’s name and address. Alternatively, users can fill in the part number first, and the other three fields are filled in automatically. This is an impor- tant feature for two reasons.
First, it reduces the amount of information that the user has to look up and type in. Second, the information that is immediately at hand will depend on the source of the reported problem. If the customer re- ported the problem, the user may not know the die number, but if the foundry reported the problem, the user would have to look up the part number. The program prints out PCRs and 8D reports by interacting with Microsoft Word. In addition, the PCR system has features that automate the sending of acknowledgment faxes to the customer, and for producing part analyses, pie charts, and so on, for viewing PCR- related statistics.
When a problem occurs with a part, a new PCR needs to be input into the system. The problem may have been raised by the customer or by the foundry itself. Either way the method is the same. The user selects New PCR from the menu and types in the information required on each page, and then saves the PCR. A separate form lets the user select an existing PCR for viewing or editing (shown in Figure 5.5).
The system helps the user find a case-based match to the PCR cur- rently being viewed; simply selecting Similar Cases from the menu does this. A form showing a progress bar is displayed for a few seconds while case retrieval takes place. The form showing the matched cases is then displayed (see Figure 5.6). If users wish to change the parame- ters, they can access these from the Advanced tab and then click on the Find Cases button to try again. The Breakdown button displays a form that illustrates numerically how well each parameter of the selected case matched against the original PCR.
Benefits
Currently each foundry has about 200 PCRs in their database. The addition of cases to the system replaces the old quality procedure that involved writing out a PCR and 8D report by hand and circulat- ing it among foundry personnel. It should be obvious therefore that the new system represents a considerable time saving, since the foundry personnel can access all the PCRs from any PC terminal on site.
Using CBR provides the cornerstone for helping us to build up, manage, and reuse troubleshooting knowledge to improve product quality in the foundries. It provides excellent data for creating a realis- tic Process FMEA report and, even beyond that, for deciding on in- spection and control checks in the foundry itself.
The individual benefits of the PCR system are:
■ Improved quality control. Structured recording of foundry problems and their solutions provides the foundry quality manager with clear, well-classified information about the main issues with pro- duction within the foundry.
■ More effective troubleshooting. Efficient access to records of past per- formance means that experience is not lost. Past solutions are al- ways available to help with present problems.
■ Realistic FMEA reports. If FMEA reports are written without refer- ence to live foundry data, they can be divorced from the real prob- lems faced in the foundry. The incorporation of the case-based data means that the design analysis for new products is grounded in real foundry experience.
As a whole, the system closes the loop between today’s problems of manufacturing and tomorrow’s designs, moving the foundry toward problem-free production.
Conclusion
Knowledge management methodologies such as CBR can be usefully employed for troubleshooting and retrieval of knowledge for other purposes. The raw material for a case-based knowledge management system can often be found in existing paper-based systems. The QPAC PCR system and Wayland are examples of systems that have been built based on existing foundry knowledge from paper files.5
Quality systems can be implemented more effectively if designed as part of an integrated set of tools. Statistical records, troubleshooting data, and process design can be useful sources for other systems such as automation of Process FMEA.
Knowledge management adalah konsep dan jargon besar yang susah diimplementasikan. Apa saking sulitnya dipahami sehingga susah diimplementasikan? Atau apa karena perlu tool yang mahal dan canggih sehingga tidak mudah diterapkan? Atau mungkin karena dosen dan pengajar knowledge management terlalu berteori setinggi langit sampai malah lupa untuk memanage pengetahuannya sendiri? Hehehe mungkin terakhir ini jadi faktor utama. Menurut saya, knowledge management itu mudah, murah dan wajib menjadi perilaku keseharian kita. Ini topik diskusi yang saya angkat ketika mengisi Workshop yang diselenggarakan oleh Divisi Komunikasi (Communication Team) Pertamina beberapa waktu yang lalu. BTW, Workshop ini dilakukan dalam rangka mensukseskan program Transformasi Pertamina menuju persaingan baru. Selain saya yang membawakan tema Knowledge Management dan Learning Organization, di jadwal tertulis nama Prof Roy Sembel yang menyajikan tema Investor Relation.
Kalau nggak percaya cek animasi di bawah deh, itu contoh mudah knowledge management.
, soalnya memang bukan untuk nyari kerja. Saya biarkan pekerjaan yang mencari saya. Lho kok bisa? Saya biarkan google dan seluruh 