Abstract
Although failure reporting, analysis, and corrective action system (FRACAS) has two management perspectives, its tasks and related information, the previous researches and applications mainly have focused on the data management. This study is to develop a process-oriented FRACAS which supports the operation of the failure-related activities. The development procedures are (1) to define the reporting and analysis tasks, (2) to define the information to be used at each task, and (3) to design a computerized business process model and set the attributes such as durations, rules, and document types. This computerized FRACAS process can be activated in a business process management system (BPMS) which employs the enactment functions, deliver tasks to the proper workers, provide the necessary information, and alarm the abnormal status of the tasks (delay, incorrect delivery, cancellation). Through implementing the prototype system, improvements are found for automation of the tasks, prevention of disoperation, and real-time activity monitoring.
1. Introduction
Recently, the reliability of products or services is recognized as a key factor to accomplish the competitiveness of a company. Reliability refers to the ability of a system or a component to perform its required functions under the stated conditions for a specified period of time. In reliability engineering, it is important to collect and analyze the related information in diverse phases, development, testing, production, and operation. FRACAS is a management tool which is established to identify and correct deficiencies in a system or a component, and thus prevents further occurrence of them [1]. Its objective is to provide engineering data for corrective actions, assess historical reliability performance (mean time between failure, mean time to recover, availability, etc.), develop patterns for the deficiencies, and provide data for statistical analysis [2].
FRACAS is composed of various components such as engineers, equipment, documents, product specifications and organizations. Also, it has been widely implemented in diverse industries which are larg sized and complicated with many participants and organizations such as military [1], aerospace [3], railroad [4], nuclear power plant [5], medical [6], and distribution industry [7]. Many of difficulties in implementing FRACAS come from these features. Hallquist pointed out that the major problems are complex organization interaction, inefficient and ineffective data tracking, and a lack of prioritized goals [8].
Normally, the management of FRACAS has two main perspectives, the reliability related information and the operational tasks. The information includes field data, failure report, specifications of products or parts, and profiles of related engineers. The elements of the tasks of FRACAS are the things about how FRACAS will be conducted, such as work procedures, workflows, regulations, ownerships, responsibilities, and organizational structures.
Because the failure handling actions generally begin with data gathering, the initiative studies have focused on effective collection methods for the field data [7, 9]. They focused on the methods to collect the failure data of products in order to deliver them properly to the relevant engineers without any loss. The main reason of data management is the feature that the application area of FRACAS has huge amount of data to be handled. As information technologies advanced, researchers have concentrated on development of an integrated reliability database. In this way, the data can be systemized based on well-defined and structured data models to maximize accessibility for the users [10]. The database supports to upgrade the failure data as information that can be used for the improvement of product designs [11]. Another significant approach is to integrate physically distributed data into a unified database [12] or to develop an automated data acquisition and analysis system [13]. Recent study focused on increasing effectiveness of FRACAS in consideration of real world nonideal data environment [14]. The benefits of such approaches are standardization of data formats, elimination of redundancies, higher availability and accessibility for the information.
On the other hand, recent industry requires more effective management of FRACAS in terms of its tasks and operations. Business environments are changing to be large scaled, globally located and distributed, and various types of problems of the products occur simultaneously in the relevant places. Therefore the losses which come from improper operations such as delay, wrong information, or delivery missing can be very huge and invisible. The complicated organizational structures (particularly multiple engineering groups), regulations and correlated business processes between manufacturing, testing and quality departments can be the causes of low efficiency of FRACAS [15, 16].
Recent FRACAS has been improved by incorporating the requirements of these business aspects. A significant approach is to standardize the tasks and business processes. The initiative study is to classify typical and common reliability management and analysis tasks from various related documents such as IEC, ANSI, MIL standard [17]. Standardization contributes to improve the integrity of FRACAS tasks in terms of its due dates of each activity [18]. Another approach is to reinforce the functionalities of FRACAS applications. The necessity of web-based management has been suggested by several researches [19], and the recent study adopted enterprise resource planning (ERP) for effective acquisition and management of the plant-specific data [11].
To summarize, the advanced FRACAS should be incorporated of the following features: (1) The reliability tasks and their attributes (due dates, ownership, and responsibility) have to be clearly defined and standardized. (2) The functionalities of task handling need to be provided to support automation of the tasks and control of the process. These requirements can be effectively satisfied when the tasks are managed as a business process and be developed in an integrated environment. Since the FRACAS process can be defined as a business process, it can be also developed based on process-oriented concept (particularly focusing on implementation of its closed loop) and process management tools.
This paper suggests a procedural development of FRACAS based on the closed loop process. It includes the methods to define the properties (organizational hierarchy, approval process) of the organization and the relevant information (failure modes and mechanism of products), to design each task and the business process, and to implement and execute the computerized FRACAS process on a process management tool, a BPMS. By a BPMS, the relevant participants of FACASE may be assigned their tasks sequentially by the regulations defined in the process model. When they finished the given tasks, the system will automatically forward the results to the next workers. The system continuously checks where the process is going on and whether the tasks are completed within the duration. The information such as the status of tasks, users, documents and time schedules may be automatically stored and monitored for the FRACAS supervisors so that they can refer in the next iteration.
Comparing to the other information systems, the benefit of adopting BPMS is that it provides the design phase of the business process, and supports management tools so that a FRACAS process can be easily reconfigured when a change was occurred in organizations or products. It is a great benefit for the modern enterprises which are integrated of various components, and rapidly changing. In consequence, BPMS helps improving the quality of FRACAS tasks through providing the standardized work criteria, and reducing the management cost by automations. The history of the operations can be used in the next iteration, and the ultimate goal of the proposed method is to improve FRACAS through iterations of the closed loop process.
The remainder of this paper is structured as follows. Section 2 describes the overall concept of FRACAS. Section 3 shows a process-oriented development procedure, and Section 4 shows an implementation of process-oriented FRACAS with its architecture and execution algorithms. Section 5 concludes the result of prototype system and the future works.
2. Overview of FRACAS
2.1. The Concept of FRACAS
FRACAS is a management tool to identify and correct the deficiencies in a system or a product and thus prevent further occurrence of them [1]. It is based upon the systematic reporting and analysis of failures during the phases of manufacturing, inspection, test, and operation. The closed loop feature of FRACAS requires that the information obtained during the failure analysis should be disseminated to all of the decision-making engineers and managers in the program. To do so, a FRACAS application should be able to track the reporting, documentation, analysis, corrective actions, and it should provide a recurrence control function which ensures that specific problems or failures do not reoccur. Moreover, the system has to maintain historical data to support resolution of the current problem, trend analysis and recurrence control activities [20].
The main component of FRACAS is its database management system. The database is established to store all the required data which includes records on all reported failures, failure analyses, and corrective actions. It is organized for efficient retrieval and analysis of the data to produce failure summary and status reports. The recent issue of FRACAS database is to integrate various and heterogeneous data sources along with the product life cycle.
The participants of FRACAS consist of failure related divisions. In general, a reliability engineering department is responsible for instituting and managing FRACAS. They establish the policy, provide the direction, and monitor the status of FRACAS investigations. The divisions for inspection and testing are responsible for initiating failure reports promptly as they are observed. Then the reliability engineers analyze the status and causes of the reported failures. The project management team generally reviews recommendations, coordinates analyses and test activities, authorizes the implementation of fixes or corrective measures. For the acquisition of certain critical (expensive and complex) systems and equipment, a separate failure review board (FRB) may sometimes be established specifically to oversee the effective functioning of the FRACAS. The activity of FRB is decision-making for reliability management like corrective actions.
2.2. Closed-Loop Process
A FRACAS process refers to the documented procedures for the analysis of failures to determine their root cause and then the establishment of the corresponding corrective action. This aids in the prevention of future reoccurrences by elimination of the problem areas in a product or a system. According to the survey, the biggest three reasons for implementing a closed loop analysis and corrective action system are compliance with the customer requirements and standards, gaining insights into the reliability of products, improving the next generation of product design [21].
The reason why a FRACAS process forms a closed loop is that the engineers should monitor and analyze the products continuously in order to improve their reliability. The loop provides the program with the opportunity to improve the reliability and performance through iterations of the reporting and corrective actions. Particularly, the system must provide the information about what the failure was, how and why the failure was occurred, how such failures can be prevented from occurring in the future. To do so, the documents should include the instructions for initiating problem reports, analyzing failures, and providing corrective actions. The quality of the documents will determine the effectiveness of the FRACAS for creating an acceptable solution.
3. Development of FRACAS Process Model
3.1. Process-Oriented Development
In modern manufacturing companies, the size of the reliability data and information to be handled is very large. Therefore many researchers have focused on management of FRACAS data and tried to develop a structured database so that the users can conveniently use the required data. This concept is called data-centered approach. On the other hand, a process-oriented approach is to solve the following problems. First, when the tasks are too complicated with many people and organizations, they should be clearly defined in order to avoid confusion of their relationships and responsibilities. Second, when specific rules of the tasks are forced to be abided by (e.g., task durations, regulations), it is more efficient to be defined and regulated in the management system so that the actual workers can be reminded and obligated to do them.
A process-oriented concept solves these problems by building a system based on a standardized business process model. Generally, information systems simply provide business functions to the users so that they can utilize them when necessary. However, in a BPMS, the system delivers a task to a worker with related information (job description) and the workers are forced to conduct them. If the given tasks are delayed or the submitted results are not qualified, the workers will be reminded by alerts or notifications. Effect of implementing process-oriented FRACAS is significantly expected when the business rules are strict, the number of cases (business process instances) is many, and the relationships of business operations are complicated.
In process-oriented concept, a business process model describes the ideal features for how, when, and by whom the process should be done. And the ultimate goal of a process-oriented system is to support the business process to be successfully completed as it was firstly planned. Its advantages may be shown as reduction of the cycle times and workloads, higher success rate of the process, elimination of the redundant tasks, and prompt problem handlings, and so forth.
The first step of adopting process-oriented concept into FRACAS is to define its business process. The definition actions consist of two phases, discovery and design phase. Discovery phase includes finding and setting up the tasks with their attributes from the organizations which will be implemented. Design phase is to represent them as a computerized business process model.
3.2. Discovery Phase
Figure 1 shows the steps of the discovery phase and their relevant components. In this phase, the attributes of business processes are derived from the target domain through investigation of job manuals, interviews and analysis of existing systems, and so forth. The first step is to define each task and its ownership. In this step, the organizational features, relevant divisions, authorities, and responsibilities may be involved. Secondly, based on the procedures of FRACAS, the sequence of business process may be defined. The failure information such as failure mode/mechanism, product specifications may be involved in the properties. Also, the business rules should be incorporated as due dates and priorities of the tasks. In the event, all the defined elements will be integrated as a business process model.
The results of discovery phase are the properties of FRACAS process, and the common elements (step, task description, ownership, required information) are represented in Table 1.
3.3. Design Phase
Design phase refers to the stage to make a standardized business process model. Normally, its formats are computerized in order to be represented and executed easily in IT systems. In many cases, they are represented in extended markup language (XML) or graphical notations. The tool for process design refers to a process modeling tool, and most of BPMSs provide their own modeling environment with graphical user interface.
In this study, we implemented the prototype FRACAS process in an open-source BPMS, uEngine [22]. uEngine employs its own process modeling tool, enactment engine, activity monitoring tool and process instance analyzer. Moreover, uEngine operates on web application server so that users can access it through the internet. This feature is very useful for FRACAS which has to be used by many users in distributed places. The process model consists of fourteen stages can be represented in the modeling tool, uEngine process designer as Figure 2.
This graphical process model is internally described in XML, and its properties are defined as an element, attribute, values and tags of XML. The format which is specified for business process modeling refers to business process execution language. In Figure 2, two types of activities are defined, human work and document-based task. The tasks which deal with documents such as failure observation, verification, and failure analysis are kinds of document-based tasks. Normally, the outputs of these activities are reports for test or analysis. On the other hand, human works such as incorporation of corrective action are complicated and empirical tasks. In this case, the completion of the tasks should be determined by the approval of the responsible participant.
4. Implementation
4.1. Enactment Phase
Enactment phase refers to the stage that the business processes are actually executed by a BPMS engine. In this phase, participants of FRACAS process will be given their own tasks by notification methods. The methods of notification can be e-mail, mobile devices, and so forth. After finishing their missions, the workers will report to the system through the same methods, and the process engine controls the flow of the processes and monitors the status of each activity. This part refers to an enactment service, of which the core of BPMSs.
Figure 3 shows the architecture and operation of the proposed FRACAS based on a BPMS. The architecture is composed of three parts, a BPMS, a FRACAS database and participants. In design phase, reliability engineers design the overall FRACAS process using process modeling tools. All the elements of FRACAS are considered at this stage, and the created business process model may be deployed as a form of XML definitions in the BPMS. The initiation of the process is by the users who observed a failure, and he/she submits a failure observation document to the system. The system sequentially delivers the tasks to the engineers. The information as the results of tasks may be stored into the process repository, a database which stores the result of FRACAS process operations. The information which is related to the failure may be stored into the FRACAS database.
The FRACAS database is to manage the historical data such as events, causes, failure analyses, and corrective actions. This DBMS is not product specific, but it should have the fundamental information such as failure history, failure mode/mechanism, and report/document templates. In the proposed architecture, most important function is the data interface between the BPMS and database. In most cases, the elements of web-based document can be generated from the data which was automatically retrieved from the FRACAS database. And the newly inputted data from the task performers may be incorporated into the database through the interface. The difference from database-only use is that the BPMS controls when and what kinds of data should be provided and inputted. This feature contributes to raise the accuracy and quality of the information.
4.2. Task Delivery and Monitoring
Task delivery is the core function of business process operations. The responsible participant of a task (ownership) can be defined either in the design phase or enactment phase. For example, a specified user can be fixed before the FRACAS process starts, or a supervisor can select an appropriate user dynamically in the operation. The assignment of tasks can be done by the handlers such as e-mail, web-documents, and SMS, and so forth. After being assigned, tasks are represented as running activities (activated tasks). According to the progress of the operations, their status can be shown as completed, failed, skipped, delayed, suspended, or canceled.
Figure 4 shows a screen shot for task delivery at the step of failure observation. The prototype system provides web-based task handlings in order to support FRACAS documentations. The left part of Figure 4 shows the HTML form of a failure observation report. If necessary, the web-page retrieves and shows the data from a FRACAS database to help inputting the information. The right part shows the activity monitoring tool which indicates how the process is currently doing. When all the defined tasks were finished, the system will automatically update the execution history into the internal database (process repository) and report to the supervisor the completion of the FRACAS process.
(a)
(b)
4.3. Implementation of the Closed-Loop through the Process Life Cycle
In Section 2, we stated the reason why a FRACAS process forms a closed loop. The improvement of FRACAS can be accomplished through the iterations of the closed loop, and the proposed system can contribute by providing the relevant information. Compared to the case of simply utilizing the FRACAS database, the proposed system helps raising the quality of reliability tasks by available and reusable information.
The iterative operation of FRACAS in a BPMS constructs a framework as shown in Figure 5. The loop consists of two flows, activities and product information, and three phases, discovery, design and enactment. This loop describes that how each activity gives positive affects to the information of products in order to improve their reliability.
Through analysis of the failure history, the specifications of products may be modified. The FRACAS process also should be changed by newly optimized reliability design and requirement. In design phase, the changes in products and organizations may be incorporated into the attributes of the business process model. In enactment phase, the participants of FRACAS will be given state-of-the-art information from the FRACAS database. The log data about task assignment and the feedback of the task performers may be updated into the process repository, and consequently added in the product failure history. Through the repetition of this process, the both sides of FRACAS process and the product can be continuously improved.
5. Conclusion
This study suggests the concept, procedure and implementation of process-oriented development to make an effective FRACAS. Its features are comparable to those of data-centered approach which are stated in Introduction. In data-centered approach, the objective is to maximize the availability and accessibility of the reliability data. Therefore, its main part is the database management system which includes structured information schema specified to FRACAS. Its benefits are integration of distributed data, elimination of redundancies, and higher availability and accessibility for the users.
On the other hand, process-oriented approach is on assumption that the main target of management is the tasks of FRACAS. Therefore, its management points are procedures, due dates, business rules and organizational responsibilities. A BPMS is the management tool for this concept, and it provides computerized process modeling, web-based/multi-user environment, task delivery, and history information management. Its benefits are expected ad standardized job description based on web manual, and low management cost through automated task delivery and real time activity monitoring. In addition, the business processes can be easily modified and reconfigured.
In particular, because of the unique feature of BPMSs which can orchestrate heterogeneous components and systems, a FRACAS database also can be easily integrated. It implies that process-oriented FRACAS can comprehend a data-centered system so that it can take advantages of the two methods. But in practice, integration of too many elements may increase the complexity of the system so that it makes difficult to be actually implemented. It is recommended that the integration starts from the part of core tasks which have higher priority, and proceed to less-important ones step by step.
The contribution of this study is suggestion of the procedural method to develop a process-oriented FRACAS. The ultimate objective of the proposed method aims to improvement of FRACAS through iterations of the closed loop. The cumulative reliability data may be incorporated to the computerized business process model, and the participants can refer the history information at their works. A BPMS provides the management tools to design, execute, monitor and analyze the business processes. The application of process-oriented FRACAS can have diverse aspects according to the subjects, that is, the types of failure, products, services and industries. The future work will focus on the practical issues in implementation in the industry.