Module-based QIS Modeling for Production Logistics in SME 1

This study proposes an object-oriented modelling for the quality information system as a module able to be integrated with other production logistics back office systems. Using the UML modelling tools such as component and class diagrams, the model addresses the highest level quality business processes and data structure as well as all identified providing and depending interfaces and the messaging system in a module-based framework design. The methodology and adopted procedures are explained in details of which provide a better understanding of the modelling and the possibility for the lower-levels quality data extensions following the same framework. The model is able to manipulate all quality control data for purchasing, production and remedy operation in a lot-based make-to-order production system within a defined module.


INTRODUCTION
Quality is one of the significant factors in long-run success at any organization.The main competitive edge in that matter is on the successful implementation of an effective Quality Management System (Wahid and Corner, 2009;Psomas et al., 2013).QMS deals with a great volume of information from its subordinates transforming the raw quality data into a useful format.However, the manual quality information handling is both inefficient and error-prone and particularly in an automated manufacturing environment, the quality operations can no longer be continued in the form of paperwork (Law and Tak, 2003).This highlights the significant role of IT for a successful data control and management system through a computerized Quality Information System (QIS).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 (Anderson et al., 1998;Tak and Hang, 2002).The applications such as demanding for quality information to find the quality problems in the product lifecycle as an example would be addressed efficiently (Ngai et al., 2011).In fact, the 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 et al., 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 study represents the development of the objectoriented quality information system focusing on the production logistics (i.e., inbound logistics) at the highest domain level suitable for SME environment.The main contribution of this study is within the concept of modularity paradigm.Using the objectoriented design, all the provided and required interfaces of QIS in related to the other back office production logistics information systems such as manufacturing and inventory information system are identified.Moreover, the explanatory technique used at the data modeling including providing the domain and entity meta-models using class diagrams describes the structure and behavior of the system extensively.The proposed object-oriented models are considered referential for further development in the lower abstract levels and integration capabilities with already developed system in an enterprise.
The reminder of this study is constructed in two main flowing sections.This introduction is followed by material and methods comprising of the quality information system and requirements, data modeling methods, adopted procedure for data modeling, quality system domain class diagram and quality system entity class diagram sections.The conclusion is presented at last section which is followed by the references list.

Quality information system and requirements:
Quality data is the most important basis in quality control, quality management and quality improvement and the most crucial resources in improving enterprise business.Generally and specifically at the SME environment, the Quality data is considered as quality characteristics of the item (i.e., resource, semi-finished goods, final goods) while in the quality control and management domain are treated as dynamic referential and operation data objects (Xiaoqing and Yun, 2008).Moreover, Dessouky and Kapoor (1987) proposed the concept of integrated QIS and showed that the functions of quality system should be extended from manufacturing to even the after-sales stages.
According to Xiaoqing and Yun (2008), the Quality data are classified into three types of: Moreover, according to Liu et al. (2005), the Quality data, based on its relationship to the product characteristics can be divided into two types of directly related and indirectly related.The former includes original quality data related to product structure like quality specifications.The latter mainly involves quality data resulting from quality activities ensuring the product quality.
Moreover, Law and Tak (2003) proposed the six important factors of database design for QIS to be considered in modeling development and implementation including: • Data integrity: To ensure the accuracy and constituency through integration toward eliminating the duplicate data, reducing errors, the loss of data, etc As the general consequence, the Quality information which is generally categorized as the dynamic and static information is of importance in the manufacturing environment and in fabricating integrated production logistics system.The necessity of considering the quality system as another operational module in a modular system design is highlighted.Therefore, to develop an efficient and responsive module-based production logistics information system, the Quality module as an important component is dramatically seen essential to which the other system are able to interact dynamically.Based on the identified QIS design requirements, the development of the modular QIS is discussed as follows.
Data modeling methods: Data modeling methods are formalizing data entities and relationships between entities.There are generally four main data modeling methods including Barker (1990) methodology, IDEF1x (1993), Entity-Relationship Model (ERM) (Chen, 1976) and Unified Modeling Language (UML) (Booch et al., 2000).These methods are the most common utilized methods to describe the data structure and transaction of a modeling system (Tak and Hang, 2002;Law and Tak, 2003;Rönkkö, 2006;Khabbazi et al., 2011).
Adopted procedure for data modeling: Offering a standard way of object-oriented design to visualize a system's architectural blueprints including the data modeling and database schema, the UML is selected as the data modeling tool.Next, the Quality main classes are identified through analyzing the Quality business process through case studies observations as the basic inputs.All classifiers and instance classes at the domain highest level of the system are identified.Some of the identified classes are basically the main classes in other systems that are associated with the main classes in inventory which thereof are referred through the attribute data types of the classes.Next, the relationships among the main classes are determined.As the result, the Domain class diagram is generated.Although, the Domain class diagrams provides general structural view of the system including the actors and interfaces but one of its significant applications is on specifying the dynamic repository classes named as the Entity classes.Next, the entity classes will be specifically elaborated.The scopes, attributes, data types and possible methods/operations of identified Quality system domain class diagram: Quality system presumably is run at the Quality division (e.g., Quality Dept) and Quality Staff are responsible for all the activities of the system.However, the otherwise is of no consequences as long as system authoritative is defined and preserved.This module supports all the operations required to control the quality of finished product as well as work-in-progress items (i.e., semifinished goods) and quality control of the purchased items including outsources and raw materials.It is also responsible for other quality operation and decision making process and sub-processes required at quality remedy cases such as segregation and ratings of detected faulty items in rejected lots based on the Quality Assurance (QA) and QC instructions.Based on the received production plans and QC operation request from the Shop floor 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.
Quality system is composed of five general internal components of Purchase QC, Production QC, Quality Remedy, Q Plan and QC instructions and OPC.As is illustrated in Fig. 1, the required and provided internal and external interfaces are identified through which the system can work properly and efficiently.External interconnections are to acquire detail information about production planning, OPC draft and purchase from the Production and Order systems.These identified interfaces determine the dependency (i.e., required) and realizing (i.e., provided) information from and for the external systems that might be included either as the other integrated production logistics modules (i.e., system components) or as the external back office systems.
Table 1 displays a classification of all identified involving Classes at the Quality system module including Actors, Departments, Interfaces, Notifications received, Enumerations, Common and Entity classes.The Quality Staff is the only identified actors within the system.Quality system has cooperative relationships with Sales Dept, Production Dept, Shop floor and  QA Instructions, QC Instructions and OPC interface classes are used with dependency associations but QA and QC instruction planning process and subprocesses as well as defining the QC station at OPC generation process are out scoped logistics data modeling and therefore not concerned in here.Figure 2 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 "one-to-many" purchase notification as PN from Sales Dept and it gets into action later upon receiving the "one-to-many" 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 Purchase QC 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 "one" QC class instance (i.e., record) there might be "zero-to-many" instances at Purchase QC class which the "zero" implies no purchase quality control is associated and there are other possible quality control operations are associated with that particular instance.The "many" implies a set of quality control operations and thereby many instances (i.e., records) are generated at Purchase QC class.The result of that given set of QC operation for the purchased batch of items will be issued and sent to Sale Dept and the Warehouse which are responsible for the destiny of the purchased items.As such, "one-to-many" Purchase QC instances are gathered in "one" purchase QC result document as Pur QCR demonstrated by the "Aggregation" relationship.The system uses Purchase Lookup and QC Instructions to work appropriately in this part of business process.
Quality system is noticed to be prepared by receiving "one-to-many" production plans as PPD from Production Dept and get into action by receiving "oneto-many" QC operation request notification as QCOR from the Shop floor 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 Production QC 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 value-added items to be stored back again at the Warehouse.Focusing on OPC numbers and QC stations all the data are classified and registered.Therefore, "one" QC class instance is associated with "zero to many" Production QC 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 Shop floor which is responsible the produced valueadded 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, "one-to-many" Production QC instances are gathered in "one" production QC result document as Pro QCR demonstrated by the "Aggregation" relationship.The system uses PP Lookup, OPC, Operation Lookup and QC Instructions 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 Quality Remedy class.Therefore, "one" instance of Production QC class invokes "zero-to-many" instances of Quality Remedy class and "one" instance of QC class is referred to "zero-to-many" instances of Quality Remedy class.Both "zero" s in the mentioned relationships imply those instances which are not associated with the instances of Quality Remedy class.After the registration of quality remedy operation, for "one" instance of Quality Remedy class, "one" instance of CRPN class associated with the "Aggregation" relationship type will be sent to Sales Dept 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, Purchase QC, Production QC, Quality Remedy and Discard are identified as the main Entity Classes in which the fundamental specific dynamic Quality System data will be stored.Pur QCR and Pro QCR classes help the system work responsively by notifying other modules about the quality control results.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.SSIN is helping at clerking affairs once segregated items are sent to the Warehouse.Lot and Relation are those of common classes that register the generated lots which are issued through Quality system due to the possible quality remedy operations.These Classes are elaborated next with their keys, attributes, data type scopes and relationships with each other.Figure 3 displays the final view of Entity class diagram for Quality system.
The data generated by the quality control and operations at one quality station for one particular batch The generated data by quality control operations for the purchased items will be stored at Purchase QC 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, "one" instance of QC class is associated with "zero-to-many" instances of Purchase QC class.The zero implies those instances of QC class which are not associated with Purchase QC class and "many" implies for one instance of associated QC class there might be several instances of Purchase QC class.In a similar pattern, all the generated data by quality control operations for the value-added items will be stored at the Production QC class in details.
Quality remedy operation is registered at the Quality Remedy class."one" instance of Production QC class invokes "zero-to-many" instances of Quality Remedy class where zero implies the "Accept" results of the production QC operations.There is "one" instance of CRPN class for each instance at Quality Remedy class."zero-to-many" instance of the Quality Remedy class will trigger the registration of "zero-toone" instance of SSIN class made by Quality Staff.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.

DISCUSSION
Quality data as another operational dynamic data in manufacturing information system are the basic requirements in many applications such as tracking and tracing information, analyzing quality-related issues and design and improvement the quality business processes.This can only be achieved reliably once the designed quality information system is able to cooperate efficiently with other back office system and therefore an integrated QIS is considered as the final solution in such effort.Small-to-medium enterprises are the highest concerns in this paradigm since the adoption of such transformation seen more necessary nonetheless less systematically practiced.However, due to the lower complexity of SME operational systems, relatively a moderate reengineering operation seen required.The quality data modeling in the literature specifically designed for the SMEs are less concerned profoundly and integration ability is yet less emphasized.Most of the developed models and proposed techniques and frameworks for QIS are basically made as a solitary system no matter how well the modeling conduction carried out and explanations are organized or comprehensive.The proposed modulebased QIS model in this study using the object-oriented technique in analysis and design make it outstanding among them.The model is based on the careful business process analysis and classes are identified systematically through business process models.As it was explained in Table 1 and illustrated in Domain class diagram in Fig. 2, all the Actors, Units and Interfaces are identified which makes it possible for inter-connection recognitions at integration process with other already existing back office system in an enterprise or for the new extensive unified system design.It delicately described what requirements are needed for the system to work properly and what are needed from which given systems and how and through which class.Moreover, it demonstrates what the QIS can provide for other systems through Lookups and to which class they can be connected through complete definitions of the relationships structure and cardinalities among the entity classes within the system.Furthermore, all required sending/receiving notification to or from other systems are identified which are essential for a modular-basis system design and development.Comprehensive and deliberate logical data model for entity classes at Fig. 3 emphasizing on attributes and data type sets, demonstrate the precise primary and foreign keys that are required for each entity class.As it was explained, some attributes as the foreign keys in transformation to the fields at database blueprint Tables are linked to the classes from other cooperative systems.For example, the "OID: Order" attribute at QC Class is one of the FKs.The associated data record in Order Class which is considered as a class in other systems is determined through Lookups such as PP Lookup, Purchase Lookup, or Operation Lookup which were mentioned at Table 1.Moreover, since the modeling is carried out at the highest domain level of the quality business processes, it is absolutely inductive for further development in the lower levels following the same framework and object oriented technique that as a consequence makes it as a reference model framework in the field.

CONCLUSION
This study focused on the modular-basis development of data modelling for production logistics quality information system at its highest domain level of business processes.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 which are required for the integration purposes with the other back office systems in production logistics are identified and addressed in the models.As such, the structure of the messaging and notification in the modular-based design are determined.The entire data modelling procedure achieving the UML domain and entity class diagrams to demonstrate the system structure, behavior and the database blueprint were explained.As an independent module and able to integrate with other systems, the module-based data models are capable to manipulate the production logistics 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.
The designed model is limited to inbound QC resources within the enterprise where outsource quality operations are not modeled.To keep the model as referential template, only highest levels of quality business processes are modeled.Since the solution is a research note in manufacturing control and logistics systems, the data model is initially applicable to environment with identical operational boundaries and complexity.It is expected that such a data model can be further developed in a way that can be integrated in the middle-level (e.g., knowledge management) or executable level to advocate quality control system effectively.

Fig. 1 :
Fig. 1: Quality system component diagram entity classes as well as the multiplicities of their relationships are conceptualized.As the result, the Entity class diagram which is used as the database blueprint on developing the prototype information system is generated.

Fig. 2 :
Fig. 2: Quality system domain class diagram Warehouse classes by sending and receiving messages and notifications of PPD, QCOR, PN, PAN, Pur QCR, Pro QCR, CRPN and SSIN.Quality system module provides information on requested lookups by realizing the top three Interface classes of Purchase QC Lookup and Production QC Lookup and Quality Remedy Lookup while depends on received information it acquires from the remaining Interface classes named at Table 1.The Entity classes listed at the last column are the one that stores dynamic data into them including issuing messages and notifications.Common classes of Lot and Relation have been appeared at Production system module.At Quality system domain class diagram, they provide a better view on the relationship between QC done on Lot and also to demonstrate the

Fig. 3 :
Fig. 3: Quality system entity class diagram of item either the purchased resources or value-added 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 Purchase QC 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, "one" instance of QC class is associated with "zero-to-many" instances of Purchase QC class.The zero implies those instances of QC class which are not associated with Purchase QC class and "many" implies for one instance of associated QC class there might be several instances of Purchase QC class.In a similar pattern, all the generated data by quality control operations for the value-added items will be stored at the Production QC class in details.Quality remedy operation is registered at the Quality Remedy class."one" instance of Production QC class invokes "zero-to-many" instances of Quality QCID: int): Is composed of information about associate lotID: Lot; Related OID: Order; Related PPDID: PPD; and Result of QC operation as for lot with QC Status: QC Status.QC status: Is enumerated with accepted and rejected.Purchase QC (pur QCID: int): Is composed of associated QCID: QC; Related purchase ID: Purchase Order and PANID: PAN; Information about the item as SKU: Item; Information about the QC operation tests like test Operation Name: string, test Location, reference Doc, start Date, End Date; Responsible staff ID: Staff; and result of each QC operation test through QC Status: QC Status.Pur QCR (pur QCRID: int): Is generated from all purchase QC operation test which are carried out at one related QCID: QC.Production QC (pro QCID: int): Is composed of associated QCID: QC; Related QCORID: QCOR; Related opr ID: Operation; Information about the item as SKU: Item; Information about the QC operation tests like test Operation Name: string, OPCNo: int, reference Doc, start Date, End Date; Result of each QC operation test by QC Status: QC Status; and responsible staff ID: Staff.Pro QCR (pro QCRID: int): Is generated from all production QC operation test which are carried out at one related QCID: QC.Quality Remedy (QRID: int): Is composed of associated QCID: QC; Invoked by pro QCID: Production QC; for lot ID: Lot containing SKU: Item at associate OPC No with failure Name: string; Information about QR Operation Name: string and QRA mounts And Results: string, start Date, End Date and reference Doc; and responsible staff ID: Staff.CRPN (CRPNID: int): Is generated for each quality remedy operation containing related QCID: QC and QRID: Quality Remedy instance.SSIN (SSINID: int): Is composed of related QCID: QC and QRID: Quality Remedy instance; and responsible staff ID: Staff.Discard (discardID: int): Is composed of related QCID: QC and QRID: Quality Remedy instance; responsible staff ID: Staff; and information about discarded item such as SKU: Item and discard Amount: int.

Intermediate data: Are produced in the course
• Static data: As closely related to QA requirements embodies enterprise's quality environment in a certain period and varies with the enterprise's environment change such as organizational data, personnel data, quality specifications, standards and etc.

Table 1 :
Quality system domain classes Production plan lookup; OPC: Operation process chart; QCOR: Quality control operation request; PN: Purchase notification; PPD: Production plan document; PAN: Purchase arrival notification; QC: Quality control; Pur QCR: Purchase quality control result; CRPN: Compensation rework production notification; SSIN: Store segregated item notification