Development of a Quality Management System based on a Platform for Customized Application of Small & Medium Manufacturing Enterprises

2.1 Structure and Distribution Type of Manufacturing Information System

The manufacturing information system can have various structures depending on the operating environment of the manufacturing company, or the viewpoint of the supplier. Chin, S. Y., Kim, K. R., and Kim, Y. S.⁵ proposed a process-based QM system with three layers of UI (User Interface), Function and DB (Database). In addition, Yang, X., Moore, P. R., Wong, C. B., and Pu, J. S.⁶ proposed a component-based PLM system that can link the manufacturing information and the components using an API (Application Programming Interface). As the operating environment of the manufacturing information system continuously changes, a multi-layered information integration system⁷ and a cloud-based information system⁸ structure have also been proposed. However, working from the premise that users control the manufacturing information, the manufacturing information system structure generally consists of service, function, and DB layers.

From the perspective of the demand manufacturing enterprise, the manufacturing information system is divided into a packaged system and a customized system.⁹ The packaged manufacturing information system analyzes the business process of many manufacturing companies to derive the standardized business process and develop the related system functions on this basis. Such a packaged system is advantageous in that it has a relatively short installation time and low introductory cost when introduced into a manufacturing company. However, as the functions of the system are standardized, it is frequently not suitable for the performance of a specific company. In contrast, a customized manufacturing information system is developed to meet the business process needs and requirements of the manufacturing company. However, it has the vulnerability of taking longer and being more expensive to build than the packaged system.¹⁰

SMMEs prefer to introduce packaged manufacturing information systems because they have to build information systems within a limited budget, but they are rarely successful when it comes to the actual development and operation of such systems. To solve this problem, Park. J. K. and Gim. M. S.¹¹ proposed a built-in ERP system by developing the ERP functions for the manufacturing process of the company, and then by combining the functions that are suitable for the manufacturing companies. This has the advantage of building the customized system, but is disadvantageous as well because the combinations can be so diverse for different manufacturers that it is difficult to maintain and manage the system.

Therefore, this study proposes a platform-based QM system that builds a system by combining common quality functions that all manufacturing companies need to perform with optional functions based on the characteristics of each company.

2.2 Business Support Range of QM System

The QM of manufacturing companies is involved in the whole product life cycle, from the product planning stage to the product shipment and warranty service stage. Since the quality control area is very wide, research on the development of quality control systems has been carried out for a long time. In terms of product planning and design, research has been conducted on the development of the QM system¹² supporting the product development process, and the integrated system¹³ supporting the product development tasks by integrating the design quality information and the production quality information.

As the production stage directly affects the product quality, various quality control systems have been studied. For example, a system that automatically determines the inspection results using a vision system¹⁴ and a system that collects and analyzes the quality information in real time in various processes using various sensors^15,16 were proposed. Most proposed systems were site-based monitoring systems capable of comprehending the field situation and diagnosing the process. In addition, a system for managing the quality history by collecting and accumulating the quality information to construct the quality bill of materials (QBOM)¹⁷ and an ontology-based quality prediction management system that can compare the quality prediction rules generated based on collected process information and the real-time process information¹⁸ were also proposed. In the shipment and warranty service phase, the automatic quality inspection system¹⁹ was studied by linking the ERP system and the MES for the quality warranty and improvement and using the data mining technique.

The QM system supports quality work according to the characteristics of the manufacturing domain through various methods. However, it is very difficult for SMMEs to introduce the quality management system for each business domain. Furthermore, even if several quality control systems are introduced for each business domain, integrating and operating these systems can cause bigger problems. Considering this, Suh. Y. H. and Kang H. S.²⁰ proposed a model and implementation plan of a company-wide QM system from the perspective of quality administration rather than the traditional QM concept. Shin, Y. S., Park, M. H., Jung, S. B., and Lee, S. C.²¹ proposed an evaluation system that can evaluate and maintain the KPIs (Key Performance Indicators) used by SMMEs. Kim, S. K., Shin, S. H, Lee, Y. S., and Chung, T. Y.²² carried out a study on a BPM (Business Process Management)-based QM system. And Choi, S. H., Kim, H. S., and Lee, G. Y.²³ suggested the need for a company-wide QM system by proposing a statistical QM process based on a TMMi model.

This type of company-wide QM system has the same support range as the platform-based QM system to be developed in this study. However, there is a difference, in that this system has been developed to reflect the requirements of the manufacturing company's business processes, work style and procedures, as well as the standard quality requirements such as ISO family. In other words, this study is meaningful as it proposes a QM system that can be customized for each company by combining the advantages of the package-type system and the customized-type system, which enables company-wide QM work.

3.1 Deriving the Required System Functions

The first step in deriving the functions required by the QM system is to identify the manufacturing process of the target SMMEs and to collect and analyze the requirements through the QM-related documents and the interviews with stakeholders to derive the required functions of the system. In this study, BPMN (Business Process Modeling Notation) was used to express the flow of information related to manufacturing activities. Fig. 2 is an example of the BPMN model that represents the manufacturing activity and information flow of an SMME at the highest level.

Fig. 2

Example of manufacturing business process analysis of SMME (top level)

In this example, as the company performs collaborative manufacturing activities with a supplier and a customer, the scope of quality work covers the supplier and the customer companies as well.

This study identifies and analyzes the manufacturing business processes for 30 SMMEs. Although there are some differences in the level and scope of work, the results of this analysis show that approximately 60 business activities are performed by the SMMEs, and 20 activities of them are directly or indirectly related to QM. Through interviews with relevant stakeholders (quality department, management, etc.) and an analysis of relevant documents in the area of quality related business activities, this study derives the functions required for quality business performance. The required functions derived through the analyzed manufacturing process are assorted, and the related ones are grouped together. Through this process, a total of 62 user-required functions are grouped into 18 groups. Of these, 13 functional groups are the groups of common functions that are essential for performing quality services and the remaining 5 functional groups are optional functional groups that can be selectively used for each company (see A1. Derived required functions and grouping result). Here, the common groups include the items required by the standard quality (ISO 9001: 2015) for product and service development, performance evaluation, and improvement, and they are interpreted as the minimum business activities necessary for the quality business in the manufacturing enterprise.

3.2 Detailed Functions of Platform and DB Design

As mentioned earlier, the basic concept of this study is to pack the derived common function groups into a form of QM platform. The second step in the platform design is to redefine the functions contained in the common functional groups, and organize the information flow between these functions. As shown in Fig. 3, this work is done using the IDEF0 model. Fig. 3 shows the IDEF0 model that represents the redefined functions and information flow for the Customer Complaints management group, one of the common functional groups.

Fig. 3

Functions and information flow of Customers' Complaints management group (IDEF0 model)

The Customer Complaints management group has three functions: Customer Complaint registration, Customer Complaint countermeasure registration, and validity check of Customer Complaint countermeasure result. Customer Complaint registration is a function to register the complaint information (customer information, product model, defect information, date of occurrence, etc.) with regard to the product reported by the customer in the QM system by the person in charge of the quality department. The Customer Complaint countermeasure registration is a function to register how the related personnel should solve the Customer Complaint based on the Customer Complaint information that has been sent and the Customer Complaint schedule information (planned completion date of the countermeasure, person to notify, etc.). Finally, the validity check of the result of the Customer Complaint countermeasure is to check whether the registered countermeasures are valid by examining the registration information of the Customer Complaint countermeasure (the countermeasure completion date, countermeasure contents, etc.) transmitted to the person in charge of the quality department.

The third step in the platform design is to design a DB based on the information organized by common function groups. The DB design should organize all the information used in each functional group into a group, eliminate redundant storage of information items, and establish associations. That is, the information items existing among information groups are organized into a specific information group to be physically stored, establishing a reference relationship with other information groups. Fig. 4 is an example of a part of the DB design result, showing the interrelationships between the Customer Complaint management information group and the other related information groups. Since the information on users, departments, and employees is used not only in the Customer Complaint management information group but also in other function groups, and system management sectors, a separate master information group is created for its storage. In summary, the information on users, departments and employees is referred to by the Customer Complaint management information group from the master information group, and the cost information resulting from the processing of Customer Complaints is referred to from the quality cost information group. Remaining items such as Customer Complaint contents and occurrence date are stored and managed in the relevant information group.

Fig. 4

Correlation diagram of customer complaint management information group

3.3 Design of User Interface (UI)

The next step in designing a QM platform is the design of the user interface for each redefined function. UI design is a process of creating screen images according to functions, and drawing up descriptions and consideration items. That is, based on the UI design, the system developer develops the screen for each function.

Fig. 5 shows an example of the UI design of the Customer Complaint registration function, showing the screen image, descriptions and considerations. In this way, the user interface for each function of the quality management platform is designed.

Fig. 5

UI Design for customer complaint registration function

3.4 Structure of QM Platform

In general, the QM platform has a three-layer structure that includes the service layer, function layer and DB layer. As shown in Fig. 6, the service layer consists of the user interface area and the supporting service area. The UI area is a set of user interfaces designed in Section 3.3, through which the functions provided in the function layer of the QM platform are invoked. The supporting service area is required to perform the quality control tasks, which consists of a combination of user interfaces. Therefore, the support services are executed independently of each other, and can be defined and registered differently for different companies.

Fig. 6

Structure of QM Platform

The basic support services provided by the platform include a total of six services: customer’s quality inquiry service, supplier’s quality service management service, quality business registration/inquiry service, manager’s quality service management service, management’s quality service management service, and system management service. For example, the customer’s quality service inquiry service is the service used by a customer of the relevant company to inquire about the status of a quality complaint for a specific product that the customer has submitted. The system management service is a support service that performs the overall operation and management of the QM system.

The function layer consists of thirteen common function groups and one system management group. Each functional group includes several functions (Fig. 6). Since the individual functions provide the independent user interface at the service layer, the scalability of the function utilization is very free. In addition, the function layer provides an API-based functional interface for linking the internal functions.

The DB layer is an aggregate of necessary information for operating the QM platform, enabling its input / output, storage, and systematic management. The DB layer is composed of the master information group which is commonly referred to in the system and 12 information groups related to the common function group. The API-based DB interface serves as a window for linking all the information in the DB layer, with which it is linked to the optional module outside the QM platform as well as the function layer.

4.1 Implementation of QM Platform

SMMEs have different use environments, utilization levels and maintenance plans for manufacturing information systems. For this reason, the QM platform should be implemented to be able to run in various operating environments. Some SMMEs do not like operating external information systems because of the risk of information and technology leakage and the need for security. Furthermore, most of these companies do not pay much attention to the maintenance of the information system because they consider the introduction of the system simply as a hardware purchase. As such, an information system introduced is used without maintenance, and is mostly allowed to become obsolete over time. In recent years, some SMMEs have come to understand the concept of borrowed software, and to take advantage of the information system's capabilities in the cloud environment. This has the advantage of enabling SMMEs to reduce the burden of system construction costs, and more easily receive maintenance and support services.

The QM platform proposed in this study is designed to be able to build a system in a specific company or in a cloud environment. The development environment for the QM platform is .Net C# and Microsoft SQL 2013, which supports the .Net Framework-based Windows operating system. Therefore, the implemented QM platform can naturally operate in an IDC (Internet Data Center)-based cloud environment (Fig. 7).

Fig. 7

Implementation screen of QM platform, (a) Customers’ complaint registration screen (b) Monitoring function by process (X-R chart) screen

4.2 Application Case of QM System

In this study, the QM system was applied to an SMME that actually produces the parts based on a quality management platform. Company D is an SMME that manufactures the attachment parts of excavators; as of 2016, it had annual sales of 60 billion won and 100 employees. Company D mainly carries out quality control work by inspecting semi-finished products in the manufacturing process. Company D is suffering from the following problems: import inspections of parts supplied from 70 suppliers are missing; or, the tasks are duplicated or the omission of information transmission does occur due to concurrent service execution by the service management department and the quality control departments in the event of a customer complaint. In addition, since company D manually manages the assembly history of its finished products, it often struggles to respond to customers' audits due to damage or loss of related documents.

Company D attempted to build a customized quality control system several years ago, but the system was not properly constructed because the construction period became too lengthy and the construction costs increased. Seeking a return on its investment, Company D tried to use some of the functions of this incomplete QM system, but ultimately discarded the system because the functions were not suitable for its business and the maintenance was too difficult.

Company D has constructed a QM system by adding an optional module (2 functions) to the QM platform. The optional module has the purpose of managing the history of the parts used in the finished product. It consists of the assembly history card creation function and the assembly history inquiry function. The assembly history card creation is a function that generates a history card by inputting the unique number of the part based on the number of the finished good. The assembly history inquiry is a function to query the quality history generated by the functional execution of the QM platform based on the number of the part. Fig. 8 shows the main screen of the Company D’s QM system and the screen of the cylinder/piston assembly history card creation function.

Fig. 8

Example of Company D’s QM system screen, (a) Main screen of Company D’s QM system (b) Screen of assembly history card creation

Company D built the QM system based on the QM platform through the business analysis and the derivation of additional requirement functions for 3 months (February - April 2016), and tested the system by applying it to the work for 2 months (May - June 2016). After system stabilization, an analysis was conducted for 12 months (July 2016 - June 2017) on the effect of applying the QM system in Company D. The application effect was evaluated using the operational performance and the ripple effects index proposed by the National Information Society Agency (NIA).²⁴

The index for measuring operational performance is expressed based on the functional utilization (U_F) and the difference of task performance ratio (D_tpr). Functional utilization is a measure of the level at which the functions of the system developed for business support and service provision are actually utilized, and is calculated as shown in Eq. (1). The difference in the task performance ratio refers to the difference in the task performance ratio before and after the introduction of the system. It is calculated as shown in Eq. (2) by comparing the work performance ratio before and after the introduction of the platform-based QM system.

where, F_all : Total number of functions in the system
　 　　F_un : Number of functions not used by the system
　 　　F_ln : Number of functions seldom used by the system

where, KPI_SP : KPI achievements after system introduction
　 　　KPI_SG : KPI goals after system introduction
　 　　KPI_PP : KPI achievements before system introduction
　 　　KPI_PG : KPI goals before system introduction

The index for measuring the ripple effect consists of the average number of users per day, and the reduction of work processes. The average number of users per day (U_n) is to measure the average number of users per day using the platform-based QM system for the number of workdays (D_w) per year, and is calculated as shown in Eq. (3). The reduction of work processes is the difference in the number of work days required when using the QM system and when not using it in performing specific tasks.

where, U_ln : Number of logged in user per day
　 　　D_w : Total working days for a year

Through the operational performance measurement, it was determined that the utilization rate of the system was considerably high at 94%, and the difference in the task performance ratio of the system was 30.4%, which shows that the task performance ratio was higher (83.3%) after the introduction of the system compared to the previous year's performance ratio (52.9%) before using the system. In terms of ripple effects, the average number of users per day was 28 (6 from quality management departments, 15 from production management departments, 4 from service management departments, and 3 executives) per day among the 37 system-related personnel (7 from quality management departments, 20 from production management departments, 5 from service management departments, and 5 executives). When measuring the reduction in work processes, it is important to select the target worker because the amount of work depends on the skill of the worker. In the case of Company D, two QM department workers with the same service period (5 years) were selected to compare the number of days required to handle customer complaints when using the system and when not using the system. For a month, the average days spent by the two workers from registration of customer complaints until the completion of measures registration were measured and compared. As a result, it was found that the average period required to handle customer complaints when using the system was 10 days, while the average period when not using the system was 14 days, a four-day difference on average. These results indicate that the platform-based QM system is well adapted to Company D.