Module-based quality system functionality evaluation in production logistics

Purpose: This paper addresses a comprehensive modeling and functionality evaluation of amodule-based quality system in production logistics at the highest domain abstract level ofbusiness processes ...


Introduction
Quality, as a definitive factor in all aspects of any organization assures a long-run success (Tari, Molina-Azorín & Heras, 2012). One of the main competitive edge in that matter is on the successful implementation of an effective Quality Information System (QIS) (Psomas, Kafetzopoulos & Fotopoulos, 2013;Wahid & Corner, 2009). Since, quality operations can no longer be carried out in paperwork as the manual quality data handling is extremely error-prone and inefficient, nor as an individual back office system, an integrated system provides desirable benefits in an automated manufacturing environment (Law & Tak, 2003). As a relatively new effort at integrating with manufacturing information system, the QIS increases the efficiency of any application of the production logistics information system as a broader and general perspective view (Anderson, Jerman & Crum, 1998;Tak & Hang, 2002). Hence, applications such as finding the quality problem root in the product lifecycle would be addressed efficiently (Ngai, Chau & Chan, 2011). In fact, QIS should ensure sending the right quality data to the right person at the right time. This in turn will highlight the important key role of data modeling based on a careful business process analysis as the backbone structure of the QIS development.
Besides, the quality data should not be considered as another property of the manufacturing objects such as a lot or an item or a batch of items in manufacturing control information system (Khabbazi, Ismail, Ismail, Mousavi & Mirsanei, 2011). As such, the necessity of considering the quality system as another operational module in a modular system design and development for the production logistics is dramatically seen crucial.
As a part of larger effort on conducting an extensive modeling for module-based inbound and outbound e-logistics system at the supply chain level, this paper complements the development of the quality system data modeling {see: #813} by emphasizing on the business process modeling as the perquisite step. It is then followed by the prototype implementation and functionality evaluation of the data models focusing on the quality operations at the highest domain levels. The explanatory technique used at the business process as well as data modeling provides descriptive view of structure and behavior of the system extensively. The proposed analytical BPMs and the object-oriented data models are considered referential for further development in the lower abstract levels. They are used as the roadmap for developing an actual database prototype from design steps to evaluate the functionality requirements of the quality system. The quality system requirements are highlighted and functionalities of the solution based on the identified requirements are evaluated through data queries providing real-time controllability. The modular-based design is another advantage of the proposed system proving the ability for integration with other back-office system in SMEs. The reminder of this paper is constructed in four main flowing sections. This introduction is followed by quality system and requirements, methodology description by explaining the procedure adopted for the modeling development as well as functionality evaluation, modeling development, and functionality evaluation. The conclusion is presented at the last section which is followed by the references list.

Quality System and Requirements
Quality data are scattered in different stages, individual departments and processes in various formats such as figures, reports, tables, files, and data sets. There is therefore, always a need to build an integrated quality data model to support all quality processes, sub-processes and activities throughout the whole life of a product (Tang & Yun, 2008). Base on different stages throughout a product's lifecycle, some quality data is listed in Table 1.
Quality data is the most important basis in product quality control, quality management and quality improvement, and the most crucial resources in improving enterprise business (Gerber, Dietzsch & Althaus, 2004). Quality information system (QIS) should ensure to send the right quality data to the right person at the right time and as such the business process and data modeling is a key concern in LIS development to address such needs.
Practically, the Quality data at the manufacturing perspective was considered as quality characteristics of the Product data while in quality control and management domain they are as the Operation objects (Rönkkö, Kärkkäinen & Holmström, 2007). Therefore, it is necessary to differentiate the quality data from manufacturing data at modeling to achieve a better accuracy at later integration of the information systems (Tang & Yun, 2008). Moreover, (Dessouky & Kapoor, 1987) proposed the concept of integrated quality system and showed that the functions of quality system should be extended from manufacturing down to even the after-sales stages.
Quality data are categorized as original data and derived data throughout product lifecycle. It can be classified into three types: static data, dynamic data and intermediate data. Static quality data refers to those data in enterprise that embodies enterprise's quality environment in a certain period and varies with changes of enterprise's environment. Static quality data are not varied with product process, but are closely related to the quality assurance, such as organizational data, personnel data, quality specifications, previous products' data, standards, etc. Static quality data can be modeled as a public module.

Stage Quality Data
Product strategy and planning Product strategy; product quality strategy; documentation of quality assurance plans; etc.

Product market analysis
Customer requirements investigation data;, market analysis reports; quality benchmarking reports; etc.

Product development
Product prototype model; quality plans; product quality parameters; product evaluation reports; product quality specifications; etc.
Engineering design BOM; product structures; process plans; design quality evaluation records; product quality characteristics; quality inspection plans; etc.

Purchase
Supplier data; supplier evaluation records; material data; material inspection plans; inspection data; non-conformance control data; etc.

Assembly
Pre-assembly audit records; assembly process plans; process control records; assembly inspection data; assembly evaluation reports; non-conformance control records; product quality certificates; product reliability test records; etc.

Sales and services
Sales data; customer records; complains and feedback data; product maintenance records; spare part supply data; failure mode analysis data; usable records; etc.

Recycle and disposal
Product recycling strategy; disposal process plans; product recycle evaluation report; product disposal reports; etc.  (Tang & Yun, 2008) Dynamic quality data comes from quality operations and processes in product cycle, such as inspection data, test data, evaluating reports, product quality plan, individual specifications, quality verification records and non-conformance quality records, quality feedback data from customers, etc. Dynamic quality data are the core object in quality management. These data are correlated to discrete quality management processes and activities and dependent on quality management stages and activities. The intermediate data are produced in the course of quality assurance process, such as non-conformance rate of product, faulty rate, quality cost, etc. These kinds of data can produce the final data, and have to be managed in the process (Tang & Yun, 2008).
Moreover, the Quality data can also be divided into two types according to the relationship to product structure. One is related to product structure directly and the other is related indirectly. The former includes original quality data related to product structure like quality specifications. The latter mainly involves quality data resulting from quality activities ensuring product quality (Liu, Ren, & Zhang, 2005).
Quality information which are generally categorized as dynamic and static are of importance in manufacturing environment. The definition of quality data which is different in manufacturing control information system as properties of a lot/item/batch (e.g. QC passed, QC rejected, etc.), in quality management might just be as a result of several operations or a trigger to proceed some operation. To have a suitable and responsive information system, therefore, there is a need of consideration of modular basis integration among this two set of information systems.

Methodology
Business process modeling is carried out to capture all the processes and their sequential flows as well as the flow of data and objects associated to them to describe the structure of the system and its behavior.
Close relevant case study observation and literature review are done to identify the system requirement and the business process identification. Next, the architecture of the system is organized through classification of the Processes, Sequences, Triggers and Artifacts as well as the categorization of the Actors or Units based on their operational roles and duties. The development of BPM for the system is mainly carried out initially using the BPMN standard through "happy flow" technique for the highest domain level of abstraction. The BP models are used as the main input for data modeling step using UML standard. Next, using "noun phrase" technique, the classifier and instance classes are conceptualized. Data models are constructed into two main steps of modeling domain classifiers and conceptual/logical data modeling. An actual database prototype is designed following "evolutionary prototyping" technique. Next the functionality of the developed prototype is evaluated through data scenarios and query system on addressing the system requirements.

QBPM -Quality Business Process Modeling
Quality business process modeling is to demonstrate how the quality data is created during quality operations on the transactions and transformation of adding value to the physical resource objects throughout the whole system. Dynamic quality data is generated by a number of activities at purchasing resources (e.g. raw material, outsourced products), semi-finished Work-in-process, and final products quality control which all are modeled at the highest domain level of the business process. The Quality, Sales, and Production Departments as well as the Warehouse and Shop floor are five identified involved roles in the Quality System. The Manufacturer is identified as abstract pool while the Quality Dept. as the main lane; and the Sales Dept., Production Dept., Warehouse, and Shop floor as the black box lanes.
The system is launched upon receiving the Purchasing order notification received "Message" start event from the Sales Dept. and will stay standby for the arrival notification. Over Receiving of purchased items "Receive" task from the Warehouse, the QC operation "Embedded" sub-process is carried out. The Updating quality system is the next task which registers the quality data into the system and is followed by the Issue quality result "Send" task to the Sales Department. The flow ends with an end event as it shown in details in Figure 1.
Next, a static data object of OPC generation as a result of collaboration between the Production and Quality Systems is introduced. Quality System is launched with a "Message" start event of OPC with operation stations received from the Production Dept. containing OPC document with operation stations for a particular product. The Design QC stations "User" task adds the required Quality control stations to the OPC documents and will finalize it through the Completion of OPC document "Send" task. The new OPC invokes the availability of some other controlling artifacts such as QC instructions used by production staff. Nevertheless, the system checks for any similar available quality plans by a "Data-based exclusive" gateway of Similar quality plan available of which with Yes condition leading to the Customizing quality plan "User" task and with No condition leading to the Design quality plan "User" task. Next, the new Quality plan is implicated and concurrently the QC instruction is designed and Issued later as the result leading to the end of process. Quality System is launched by the Production plan received "Message" start event through the "Attached Time" intermediate event standing by for the system until the Receive QC operation required "Receive" task from the Shop floor is executed. It is followed by the Production plan lookup "Service" task, the QC operation "Embedded" sub-process using required artifacts is made and QC results are registered with Updating QC system task and data are stored in Database as new quality records. Later Issue QC results "Send" task sends the QC results to Shop floor. Next, Result OK "Data-based inclusive" gateway controls the flow with two alternatives of Yes condition reaching to an end event and NO leading to Wait for faulty goods intermediate "Time" event. As such, upon receiving the faulty products from Shop floor, the Quality remedy operation sub-process gets activated and is followed by end event. Figure 2 illustrates Quality remedy operation subprocess in expanded mode. Base on problem analysis and possible remedy options over the faulty products, Fixable "Data-based exclusive" gateway initiates Discard goods task over No and upon Yes condition Segregation "Compensation" task is followed. Updating QC system task is the next process for either flow to register quality remedy records into Database. The segregated products are sent to warehouse and the flow is ended with Store segregated semi finished products "Message" end event. Eventually, Notify compensation/rework production plan "Send" task is sent to Production department followed by Compensation/rework production plan "Compensation" end event after Updating QC system task.

Quality System Domain Class Diagram
Quality system is modeled with assumption of running at a Quality division (e.g. QualityDept) where Quality Staff are responsible for all the system operations. This module supports all the operations required to control the quality of finished product as well as work-in-progress items and quality control of purchased items including outsources and raw materials. It is also responsible for other quality operation and decision making process and sub-processes required at the cases like segregation and ratings of detected faulty items at rejected lots based on the Quality Assurance (QA) and QC instructions. Based on the received production plans, and QC operation request from the Shopfloor at defined QC stations designated at the OPC, the quality control operation takes place and the results issued to defined destinations. The quality system manages the generated data by registering them to respond promptly with message and notifications over confirmation and verifications or at the future data analysis triggered by lookups providing the QC operation details, reasons and results. QAInstructions, QCInstructions, and OPC interface classes are used with dependency associations but QA and QC instruction planning process and sub-processes as well as defining the QC station at OPC generation process are out scoped logistics data modeling and therefore not concerned in here. Figure 3 illustrates the final view of Domain class diagram for Quality system.
Next, the cardinality of the class diagram is explained. Quality system is noticed to be prepared by receiving "1…*" purchase notification as PN from SalesDept and it gets into action later upon receiving the "1…*" purchase arrival notification as PAN from the Warehouse. Quality control of the purchased items will be carried out and the data registered at QC class emphasizing on the more general data and at the PurchaseQC class for more detail and variations of QC operations such as material analysis or measuring the dimensions. In fact, in this way of classification of data registration, the better traceability of information will be provided for one set of QC operation which is made for batch of item. It also means that for "1" QC class instance (i.e. record) there might be "0…*" instances at PurchaseQC class which the "0" implies no purchase quality control is associated and there are other possible quality control operations are associated with that particular instance. The "*" implies a set of quality control operations and thereby many instances (i.e. records) are generated at PurchaseQC class. The result of that given set of QC operation for the purchased batch of items will be issued and sent to SaleDept and the Warehouse which are responsible for the destiny of the purchased items. As such, "1…*" PurchaseQC instances are gathered in "1" purchase QC result document as PurQCR demonstrated by the "Aggregation" relationship. The system uses PurchaseLookup and QCInstructions to work appropriately in this part of business process.
Quality system is noticed to be prepared by receiving "1…*" production plans as PPD from ProductionDept and get into action by receiving "1…*" QC operation request notification as QCOR from the Shopfloor at the exact time. These types of QC operation request notifications are helpful in some cases that the QC plans are not concerned or provided in advanced by some enterprises. As such, the QC operation for production will be carried out and the generated data registered as the same way and reason as the QC operations for purchased items but in Production QC class. The ProductionQC class registers the details of QC operations for all production operations carried out on the items starting from resource items which are allocated for production initiated in one lot from the Warehouse to valueadded items to be stored back again at the Warehouse. Focusing on OPC numbers and QC stations all the data are classified and registered. Therefore, "1" QC class instance is associated with "0…*" ProductionQC instances which the "0" implies those instances (i.e. records) that are not associated in this relationship. The result of that given set of QC operation for the production items in the lots will be issued and sent to the Shopfloor which is responsible the produced value-added items and based on the QC results they carry on. This is because the QC operation is generally carried out at the production stations area depending on the condition and characteristics of the items in lots or product types.
Hence, the resumption of the production process whether to carry on or not is taken over again where the lots are located waiting for the QC results generally at the production station explained earlier at the Production System module. As such, "1…*" ProductionQC instances are gathered in "1" production QC result document as ProQCR demonstrated by the "Aggregation" relationship. The system uses PPLookup, OPC, OperationLookup, and QCInstructions to work properly. In the "Rejection" cases at production QC operation results, there is a need for decision making about the idled rejected items. This invokes some sorts of quality remedy operations to be made over the items such as the separation of accepted ones from faulty ones which is called the segregation. Quality remedy operation is carried out the generated data is registered through the QC class and QualityRemedy class.
Therefore, "1" instance of ProductionQC class invokes "0…*" instances of QualityRemedy class and "1" instance of QC class is referred to "0…*" instances of QualityRemedy class. Both "0" s in the mentioned relationships imply those instances which are not associated with the instances of QualityRemedy class.
After the registration of quality remedy operation, for "1" instance of QualityRemedy class, "1" instance of CRPN class associated with the "Aggregation" relationship type will be sent to SalesDept to notify the required compensation or reworks to fulfill the customer order. In the meantime, the discarded items details will be registered at Discard class and the segregated items will be sent to the Warehouse within a notification issued by the system to store the segregate items as SSIN.

Quality System Entity Class Diagram
The QC, PurchaseQC, ProductionQC, QualityRemedy, and Discard are identified as the main Entity Classes in which the fundamental specific dynamic Quality System data will be stored. PurQCR and ProQCR classes help the system work responsively by notifying other modules about the quality control results. The CRPN class is another notification entity class which declares the need for composition or rework due to the shortages causes by reducing the faulty product out of the produced items as the result of quality control operation. The SSIN is helping at clerking affairs once segregated items are sent to the Warehouse. The Lot and Relation are those of common classes that register the generated lots which are issued through Quality system upon any possible quality remedy operations. These Classes are elaborated next with their keys, attributes, data type scopes, and relationships with each other. Figure 4 displays the final view of the quality system entity class diagram. The data generated by the quality control and operations at one quality station for one particular batch of item either the purchased resources or valueadded items in lots are classified and sorted through the QC class initially. Therefore, through this class, realization of Quality system interface classes is facilitated through classifying in one unique QCID. The generated data by quality control operations for the purchased items will be stored at PurchaseQC class in details. Each unique operation or control which is carried out is registered and the result will be determined separately to trace the results efficiently. Therefore, "1" instance of QC class is associated with "0…*" instances of PurchaseQC class. The zero implies those instances of QC class which are not associated with PurchaseQC class, and "*" implies for one instance of associated QC class there might be several instances of PurchaseQC class. In a similar pattern, all the generated data by quality control operations for the value-added items will be stored at the ProductionQC class in details.
Quality remedy operation is registered at the QualityRemedy class. "1" instance of ProductionQC class invokes "0…*" instances of QualityRemedy class where zero implies the "Accept" results of the production QC operations. There is "1" instance of CRPN class for each instance at QualityRemedy class. The "0…*" instance of the QualityRemedy class will triggers the registration of "0…1" instance of SSIN class made by QualityStaff. The zero implies that there might be possible that all the produced items are faulty and there would not be any segregated items to be stored at the Warehouse. In both ways, either there would be accepted items left or not, the information of the discarded items will be registered at the Discard class in details. A single instance of introduced each Entity Class has a unique identification integer number as ": int" which is displayed at the data type scope section at the top attribute compartment list. The other attributes and the possible methods/operation of all classes are explained as follows. about discarded item such as SKU: Item, and discardAmount: int. Next, the prototype design particular and its functionality evaluation are discussed.

Functionality Evaluation
Based on the quality system entity class diagram, the Quality System Tables  The QC Table is to associate the quality operation data to other parts of the e-LIS. There might be several kinds of quality operations to be carried out for one particular quality request. Therefore, the QC   Table. The result of each QC operation will be saved for each test.
However, the general result of the QC is decided and will be registered at the QC Form at the bottom of the form. Next, the PurQCR will be issued. The procedure is the same for any production quality control, but at this case the details of the production QC will recorded through ProductionQC sub-form and it is saved at the Production QC Table as it is illustrated at Figure 7.  Lookups are administrated there. Table 3 demonstrates the implemented data queries and their functionalities to address the system requirements.

SSIN (SSINID)
A document in the Report format for one "store segregated item notification" including the detailed data from Lot record, Quality Remedy record and SSIN record.
Traceability. Confirmations Table 3. Implemented lookups based on designed data queries

Conclusion
This paper focused on the system development and the functionality evaluation for a module-based quality information system. The analytic models and actual prototype implementation address the need for controllability and accessibility in real-time to the quality operation data generated within all domains of the inbound outbound and production logistics system. The research was carried out to identify all business process and system requirements for the quality system and carefully addressed them at the data modelling development using UML. All quality system interfaces as well as structure of the messaging and notification are identified and addressed in the models. The entire data modelling procedure achieving the UML domain and entity class diagrams to demonstrate the system structure, behavior and the actual database were explained. Using the query system, the functionality of the developed prototype is evaluated through applying several defined queries to check the responsiveness with the system requirements. As an independent module and able to integrate with other systems, the module-based system is able to manipulate the quality data dynamically to keep the information up-to-date and provide report generating system for applications such as for Purchase QC results, Production QC results and Quality Remedy reports in real-time to support rapid decision makings with minimum efforts and or errors. As being as a referential template, only highest levels of quality business processes and in turn the classes and tables are modeled and developed. Since the solution is a research note in manufacturing control systems, the application of the research output is extendable to the identical circumstances and complexities.