Disaster Management Based on Business Process Model Through the Plant Lifecycle

There has been a recent surge in the number of disasters and incidents in occurring in the process industry (e.g. the petrochemical, chemical, food and pharmaceutical industries). The reasons include defects in process-safety management (PSM); inadequate safety management systems in companies; inadequate knowledge among managers and insufficient information about the tasks undertaken and resultant erroneous operation and/or misjudgement; no standardization for the PSM activity; and other engineering factors. Expecting that PSM will reduce the hazards and likelihood of disasters, OSHA in USA emphasizes PSM and requires that companies establish PSM systems and improve safety engineering techniques (OSHA, 1992).


Introduction
There has been a recent surge in the number of disasters and incidents in occurring in the process industry (e.g. the petrochemical, chemical, food and pharmaceutical industries). The reasons include defects in process-safety management (PSM); inadequate safety management systems in companies; inadequate knowledge among managers and insufficient information about the tasks undertaken and resultant erroneous operation and/or misjudgement; no standardization for the PSM activity; and other engineering factors. Expecting that PSM will reduce the hazards and likelihood of disasters, OSHA in USA emphasizes PSM and requires that companies establish PSM systems and improve safety engineering techniques (OSHA, 1992).
Existing PSM guidelines, OSHA/PSM, Seveso II Directive (The Council of the European Union, 1996), AIChE/CCPS RBPS (Risk-based Process Safety) (AIChE/CCPS, 2007) and others, establish only minimum elements for safety management. They do not describe concrete actions to take within facilities. The importance of discussion of process/plant engineering activities based on business process modelling throughout a 'plant-lifecycle (i.e. from process/plant design through construction and the active manufacturing period (incl. production and maintenance))' has been recognized for many years. Development of a systematized PSM framework should prevent disasters and ensure consistency within plantlifecycle engineering (Plant-LCE).
To develop a plant-and site-specific PSM approach, it is important to clarify the relationship between management and individual activities, and to consider the technical and functional frameworks within the human-organization system. Traditionally, business-process analysis has been conducted according to organizational configurations and strives to clarify responsibilities ('know-who' and 'know-what') among employees and managers. However, companies have specific organizational frameworks, administrative structures, policies or strategies of operations management, and specialized engineering techniques (individual methods, procedures, tools, etc.), and therefore the standardization of business processes and the development of generic management frameworks to which companies can refer is very difficult. The first thing necessary for practical disaster management is to make hidden business knowledge (specifically the 'know-why') explicit by focusing on functional and logical structures of the business process (i.e. the causal relations and information flow among and between business activities).
This chapter aims to discuss what should be done to business functions (i.e. activities) and what should be done to operations at a plant-site. The focus of business process modelling is mainly on engineering activities in the process industry. These activities are organized hierarchically following a template in the form of the PDCA (Plan-Do-Check-Act) cycle. The business process model (BPM) of a Plant-LCE (including PSM) is presented as an example.

Plant-lifecycle engineering
As show in Fig.1, a plant-lifecycle consists of the following engineering stages: development, design, construction, production, maintenance, and scrap (or dismantlement). It may be more than 40 years from the beginning (or development) stage to the end (or scrap) stage. Over its lifetime, the product markets and the costs of raw materials and fuels may vary dramatically. During that time, changes of production rules or strategies and/or revamping of a plant's facilities are undertaken. Underlying hazards may be found while technology is improved or as a result of accidents that occur in the industry. Furthermore, degraded plants should be renovated to meet requirements for safety, because the quality of facilities is often diminished during their production tenures. Under these external and internal environmental conditions, changes of plant structure, processes, plant design, production and maintenance are necessary. For all changes, safety assessments and improvements are always needed. Process hazard analysis (PHA) and management of change (MOC) are perpetual and vital. Many activities are needed to achieve MOC. Modification of even a small part of a plant will affect many other stages in the plant-lifecycle. Stages in a plantlifecycle are intricately connected. Most disasters occur during the production and maintenance stages of a plant-lifecycle. Researches during the development and design stages to improve safety during the production and maintenance stages help to prevent disasters. For example, plant equipment that is designed with low tolerance for operating conditions is difficult to operate safely and may lead to heightened risk, hazard and even disaster. If plant engineers can design for wider operating range, equipment is easier to operate safely and may produce few disasters. Furthermore, design based upon clear understanding of production and maintenance processes ('design rationale') can also help to avoid disasters. If the proper design rationale ('know-why') is incorporated into a facility, poor and dangerous decision making will be avoided. For systematic disaster management, a model-based engineering framework is www.intechopen.com needed so that information can be used to inform all stages of the plant-lifecycle. Constantly updated and revised data must be shared at each engineering stage in a transparent way in order to examine the impacts of safety decisions of all functions/activities of the plant. Such an information infrastructure is not currently available, so we have wasted enormous manpower to acquire or update proper information. To realize the engineering framework based on the information infrastructure, business activities and information flow among them should be represented explicitly.

Basis of business process modelling for plant-LCE
IDEF0 (Integrated DEfinition for Functional model standard, Type-zero) is adopted as a description format to develop the business process model. And a template has been proposed to generalize the modelling in IDEF0 format.

IDEF0 format
IDEF0 is a well-known standardized method for enterprise-resource planning or businessprocess (re)engineering. Fig. 2 shows the basis of the IDEF0 format. The rectangle represents an 'activity (function)', and the arrows describe information. The information is classified into four categories: 'Input' which is changed by the activity, 'Control' which constrains the activity, 'Output' which is the result of the activity and 'Mechanism' includes the resources of the activity. The information is collectively termed ICOM (Input, Control, Output, and Mechanism). Each activity can be further developed hierarchically to detail sub-activities as needed (NIST, 1993). Development of business process model using the IDEF0 format enables function-based discussions.

Template for developing business process model
The PIEBASE (Process Industry Executive for achieving Business Advantage using Standards for data Exchange) was an international consortium to achieve a common strategy and vision for the delivery and use of internationally accepted standards for information sharing and exchange (ISO-STEP), and developed a business process model to represent the core business activity of the chemical process industry (PIEBASE, 1998). The www.intechopen.com PIEBASE model uses a template approach across all principal activities. This template consists of three steps, (1) manage, (2) do, and (3) provide resources. The purpose of PIEBASE model is to provide a common understanding of the engineering and information requirements of processes throughout the lifecycle of a plant. However, the activities in the model were defined to reflect current practices.
On the other hand, as shown in Fig. 3, a template for business process modelling (BPMtemplate) of Plant-LCE has been proposed to generalize the modelling in IDEF0 format and enable a discussion of integrating each business process model for Plant-LCE (Shimada et al., 2009). This BPM-template consists of two functions; 'Performance in the form of a PDCA (Plan-Do-Check-Act) cycle' and 'Resource provision'.  (Deming, 2000): Each activity should be carried out according to engineering standards (or ESs; e.g. technical standards and control standards) complying with laws and regulations. - The 'Manage' activity manages the progress of overall activities within the same plane, including the requirement of resource provision, the improvement of engineering standard, and decision making of the next action for change requirement. - The purpose of the 'Plan' activity is to make an executable plan for a given specific directive. - The 'Do' activity executes a plan and yields requirements for administrative defect factors, if any. - The 'Check' activity evaluates the results and the performance of the previous activities to support these goals: a) performance and results for the directive and the plan, b) compliance with engineering standard, c) sufficient provision of resources, and d) validity of engineering standard itself.
2. Resource provision: 'Provide resources' activity provides the resources to support and control 'Plan', 'Do', 'Check', and 'Act' activities. These resources include: a) educated and trained people and organizations; b) facilities and equipment, tools, and methods for supporting activities; c) information to perform PDC activities; d) information for progress management; and e) engineering standard for controlling each activity, which are given from the activity of upper plane.
This BPM-template enables development of business process model to perform activity planning, execution, evaluation, and improvement at each sub-activity plane. That is, the model based on proposed BPM-template shows the implementation in the form of PDCA cycle and the uniform management of engineering standard with provision of just enough resources. And the developed model can make the purpose, the contents, and the relevant ICOM of individual activity clear.
Features of the business process model are: • Business process activities with information and information flows at each stage of the plant-lifecycle are modelled in the form of PDCA cycle. The scope of each management plan becomes clear. The decision making, evaluation processes, resources, information, and engineering standard required for performing each process are expressed explicitly.

•
All information needed to perform each activity (including the plans, the performance results and checked results) are collected, managed, and in the 'provide resource' step in the framework. The 'Provide resources' activity is to achieve consistency between engineering standards. • Business processes are structured as activities or functions that are logically required regardless of a company's organization.

•
Using the business process model as reference model should expose problems with the current process, activities that are not performed in the PDCA cycle, and any defects during information sharing and communication. The countermeasures of the problems, consolidation of technical requirements, and the processes centered on organization integration can be reviewed.

Business process modelling for disaster management
Business process model should be seen as a 'to-be' model that represents the logical business process. The following points are required for a referenceable model.

•
The definitions of business functions and the scope of them must be clarified before starting the development of model.

•
Activities that develop technologies and activities that use technologies for engineering functions should be clearly distinguished.
• Activities must be categorized as 'Plan', 'Do', 'Check (Evaluate)', or 'Manage (Act)' activities in order to develop a model that constitutes an activity framework in the form of a PDCA cycle.
Furthermore, two points must be kept in mind so as not to create a business process model that only represents a specific company's activities.
• The model should be considered separate from the company by assigning tasks based upon on organizational structure not specific workers in the specific company. That is, www.intechopen.com tasks should not be based on the question of "who should do them?", but rather on "what has to be done?" • Specific activities in an individual company should not be the focus of the model. Widely-used and generalized structures of activities and information flow related to the activities should be developed.
Activities that are performed at actual companies (plant engineering companies, plant operation companies, etc.) have been compiled and examined, and business process models have been developed based on the BPM-template displayed in Section 3. Fig. 4 shows a business process model reflecting the activities of Plant-LCE. 'Do' activities of this model are comprised of activities of development and design, construction, and manufacturing stages. Models for process and plant design, production, maintenance within manufacturing, and PSM are described in the following sections.

Business process model for process and plant design
Chemical processes generate potential hazards, and these processes are designed to avoid hazards given that they can evolve into serious events. In general, the risk is controlled within a region of safety within normal operations. However, some initiating events that exceed the control capabilities of normal operations can cause abnormal deviations and hazardous events that can lead to human and physical damages. The purpose of using independent protection layers (IPLs) (AIChE/CCPS, 2001) is to prevent the occurrence of hazardous events by designing protective systems against failure sequences that might lead to disasters. Table 1 shows the most commonly encountered IPLs that should be considered for inclusion during www.intechopen.com process and plant design. In a typical plant engineering project, the analysis that precedes the IPL design and the IPL design itself are not incorporated in a systematic way with the process and plant design. This is related to the common lack of design rationales in the design of safety systems, and these result in alarm floods (ISA, 2007). To overcome these problems, a business process model is developed to provide a framework for process and plant design.
Inherently safer process design 2 Basic process control system, process alarm and operator supervision 3 Critical alarms, operator supervision, and manual intervention 4 Automatic Safety Interlock System (SIS) 5 Physical protection (relief devices) 6 Physical protection (containment dikes) 7 Facility emergency response 8 Community emergency response Table 1. Independent protection layers A business process model for process and plant design that incorporates IPL design has been developed (Fuchino et al., 2011). This model is based on the previously discussed BPMtemplate across all principal activities, and the Plant-LCE approach was adopted as well. Fig. 5 shows a part of the node tree from "(A3) Perform Process and Plant Design" of business process model of the Plant-LCE. The process design activity consists of three phases: conceptual, preliminary, and final. The plant design is composed of two phases: preliminary and final. The conceptual process design phase (A33) corresponds to the inherently safer process design in IPL (1), including hazard elimination and substitution, inventory considerations, and plant location. The preliminary process design phase (A34) is related to the design of IPLs (2) to (6). In "(A34) Develop Preliminary Process Design (IPL-2_6)", the process design according to operational requirements of normal, abnormal, and emergency operations is executed. In designing process for normal steady state operation (A343), basic process control system is designed, so that the safety operating ranges should be assessed in A3432 activity before A3433 activity. "(A344) Develop Preliminary Process Design for Startup (S/U) and Shutdown (S/D) operation" evaluates the current plant design to verify that all the necessary equipment is available to perform startup and shutdown. As a result preliminary operating procedures are obtained along with information on operating limits and timerelated data that can be used to configure state-based alarm algorithms. The synthesis of startup and shutdown operations takes place in A3442 activity. To specify initial conditions and safety constraints in A34423 activity, the hazardous conditions should be assessed in A34422 activity. In "(A345) Develop Preliminary Process Design for Abnormal Situation" activity, PHA is necessary (A34522) and the operation category (fallback, partial shutdown, or total shutdown) is determined. This is because hazard analysis is used to identify possible hazard scenarios and its recommendations for additional sensors, alarms or other IPLs, some of which are addressed in activity A34523. Furthermore, because hazard scenarios contain information about causes, consequences, and corrective actions, they can also be used justify the design rationale for a given alarm. Operational responsibility should be estimated in A34523 activity, and the operation category is decided in A34524 activity. The activities to perform PHA are depicted in Fig. 5. It is clear that PHA and IPL design should be performed concurrently to generate rationalized process safety design. This makes it possible to manage the information www.intechopen.com on design rationale which can be useful for safety production management and effective maintenance and contributes to disaster prevention in process industry.

Business process model for production
It is essential to create the environment that can support purposeful management of safe operation and effective maintenance while performing normal manufacturing activities. The activities related to production and maintenance in the Plant-LCE are unified as manufacturing with production planning. This enables development of an integrated plan to manage production and maintenance activities together.
It is difficult to develop a unified business process model for manufacturing due to the differences with aspects of production management because of the organization of individual companies and the differences of operation philosophies of each type of plant (for instance, petroleum refineries compared to petrochemical plants and fine chemical plants). For these reasons, there have been no attempts to develop a business process model for production activities. To surmount this challenge, the following two principles have been established before starting the analysis of production: 1) The model is independent of organizational frameworks in specific companies, and 2) Specific production activities in specific companies will not be considered and only general activities and only the flow of information should be considered. Specific activities can be added to the BPM-template for use by specific companies to apply the model to real-world cases.
Business process model have been developed for production (Shimada et al., 2010a). Activities under "(A53) Perform Production", which is a sub-activity of "(A5) Perform Manufacturing", have been considered targets of business process modelling for production. At first, activities of production that are performed routinely at some companies have been listed and extracted by reference to international standard (IEC, 2003). Then, the activities and their relations have been generalized according to the BPM-template. Fig. 6 shows the node tree from "(A53) Perform Production" which consists of production scheduling, inventory control, and production execution. "(A534) Execute Production" activity consists of dispatching operations, preparation for operations, and execution of operations. Operation is comprised of operation for both normal and emergency situations, and normal operation has three main activities: operation-case execution, monitoring and diagnosis from the viewpoints of SQEA (Safety, Quality, Environment, and Availability), and construction support under plant operation. As a second step, ICOM on production management is provided to for relation to production. As information related to mechanism, people, facilities and equipment, information, consistent engineering standards, etc. needed for performing production are clearly specified and managed in an integrated manner. Fig. 7 shows the business process model for "(A5344) Execute Operation" as a part of production. The model shown in Fig. 7 do not mention about 'Plan' activity explicitly, but directives from upper level activity that is "Decided operating procedures" and "Directive of normal operation" include each concrete execution plan.
The meanings of terms in the business process model and concrete examples of activities have been written down in the glossary, which is separate from the model. This glossary can help assist discussion of the model by clarifying what, how, and why steps are taken within the model specifically. At the same time, resources needed for executing each activity are also listed. Developing a business process model for production provides following advantages: • Development makes it possible to summarize the activities hierarchically and to clarify the required inputs, the constraining conditions, and the resources needed for each activity.

•
Scope of safety operation management can be specified by extracting the structured activities of production.

•
Performing production according to the developed model makes it possible to convey process-safety information positively and to enable the prevention of industrial accidents or disasters due to PSM difficulties.

•
Introduction of a framework given as a model provides the basis of safety conscious production for the process industry.

Business process model for maintenance
Chemical plants employ a lot of flammable materials as raw materials, intermediates and products, so leakage is a serious problem that may lead to fire, explosion and/or disaster. Chemical plants are deteriorated by their production, and maintenance aims to restore the deteriorated plant into a safe condition. The mechanism, speed, and location of the deterioration vary with operating conditions (e.g. increasing flow rate in pipes sometimes change the location of sludge deposition, and the mechanisms of corrosion under the sludge). However, the deterioration (especially corrosion) is much more complicated by the chemical compounds and flows of process fluid, the plant structure (including the nature of the materials used in its construction), and electrochemical behavior. Therefore, the exact deteriorating location and level of deterioration (and/or residual life of the deteriorating part) cannot be expected from the beginning but can only identify the probabilities of deterioration locations.
In order to perform maintenance consistent with production and plant state through the plant-lifecycle, a mechanism not only to integrate the information of lifecycle activities (design, production and maintenance), but also to systematize the results of maintenance into technology is needed. Business process model have been developed for maintenance in order to define the framework of the processes (Fuchino et al., 2008. Fig. 8 shows the node tree from "(A54) Maintain Plant" of business process model of the plant-LCE. The model is based on the preceding BPM-template across all principal activities, and the Plant-LCE approach was adopted.
"(A54) Maintain Plant" activity receives directives and requirements for maintenance from "(A51) Manage Manufacturing". The information from the production plan comes from "(A52) Make Production Plan" and any other information for maintenance including operational results and maintenance results is from "(A56) Provide Resources for Manufacturing". Furthermore, engineering standard necessary to perform maintenance is delivered from A56 to A54 activities. A54 activity developed into "(A541) Manage Maintenance", "(A542) Make Maintenance Plan", "(A543) Perform Maintenance", "(A544) Evaluate Maintenance Plan and Performance" and "(A545) Provide Resources for Maintenance". A541 activity decides sub-directives for A542 to A544 activities on the basis of the directive, requirement and production plan from the upper hierarchical activities, and A542 to A544 activities are performed under the constraint of the sub-directives. The A545 receives information and engineering standard for maintenance, and the information is delivered www.intechopen.com to A542 to A544 activities. Making a maintenance plan is defined as deciding which parts and at what times to repair the plant, as well as selecting methods for inspection and repair.

Fig. 8. Node tree from "(A54) maintain plant"
The A5422 activity determines the part repaired and timing using the information from the production plan, production results and maintenance results. Repair and timing guide inspection and methods of repair from the inspection and repair data base in A5423 activity.
The results of such maintenance planning inform "(A543) Perform Maintenance" via A5425 and A5421 activities. To perform maintenance, maintenance procedure is planned in A54322 activity which is a sub-activity of "(A5432) Make Maintenance Execution Plan", and inspection and repair are carried out in A54332 and A54333 activities of "(A5433) Execute Maintenance". The results of the maintenance execution plan, inspection and repair are stored in "(A5435) Provide Resources for Maintenance Execution" together with the result of maintenance execution plan. The stored information is transferred to "(A7) Provide Resources for Performing Plant-LCE" activity via activities that are compartmentalized in 'Provide resources' on several hierarchical nodes. The results of maintenance are group into www.intechopen.com technology and engineering standard in A7 activity, and are reflected in activities at every hierarchical node. When some defects of technology and/or engineering standard are found, changes are required in upper hierarchical nodes. These changes are decided in the activities categorized as 'Manage' on several hierarchical nodes. Therefore, the PDCA cycle within and across the hierarchy can be configured, and a to-be model for maintenance can be developed. Fig.9 shows the business process model for "(A54) Maintain Plant". The output information from 'Plan', 'Do' and 'Check' activities is standardized into "Requirement of resources and engineering standards", "Change Request", "Progress" and "Certified Output", and is consistent within the hierarchies. This model can specify the system requirements for development of an environment to support knowledge management for maintenance.

Importance of systematic PSM
PSM is a management system that is focused on prevention of, preparedness for, mitigation of, response to, and restoration from catastrophic releases of chemicals or energy from a process plant. The main purpose of PSM is to maintain the safety of a production plant, and it could be realized by the Plant-LCE as shown in Fig. 10 (Shimada et al., 2010b). Plant development stage includes the periods of research and development (R&D), design, and construction of the facility. The manufacturing stage includes production and maintenance. PSM activities at the design stage are intended to design a safe process plant. Safe facilities are constructed through PSM activities during the construction stage. PSM activities at the maintenance stage are intended to maintain the www.intechopen.com integrity of the functioning of facilities throughout production. Furthermore, it is important to perform PSM activity in the form of a PDCA cycle, steps such as planning safety countermeasure based on risk assessments, execution of plans, evaluation of outputs and the sharing of process-safety information though the plant-lifecycle. And for the MOC, one of functions in the PSM system, it is also important to make decisions to respond to change by ensuring consistency among activities.

Business process model for PSM with Plant-LCE
Business process model have been developed for PSM. Fig. 11 shows an overview of PSM activities with Plant-LCE. A basic plan for PSM is considered based on a corporation's philosophy as PSM activity at the enterprise-level and PSM activities at the plant-site-level are performed to develop this basic plan. Activities at each level structure the PDCA cycle which clearly specifies planning, execution, evaluation, and improvement. 'Provide resources' activities are added to clarify the resources needed and to define the environmental conditions it requires.
The business process model for PSM has been developed by extracting the essential activities and ICOM for maintaining process safety of production plant through the plantlifecycle. Fig. 12   Furthermore, a comprehensive framework structure for the PSM has been based on the business process model for PSM. The position of PSM elements can be defined by the more concrete activities for Plant-LCE. This makes it possible to specify how each PSM element should function in the PSM system. As a result, the proposed PSM framework can be applied to improvement of a company-specific PSM system to match a business's configuration.
To ensure that the PSM business process described above is nothing less than disaster management for the process industry.

Application of business process model as a reference model
The business process model clarifies business flow in the form of PDCA cycle and the provision of resources within an IDEF0 format sheet. The hierarchies' relationship between activities represents the superior and subordinate nature of activities. This can make explicitly how concrete activities at plant-site are directed by management and how the reporting of the results of activities generates suggestions for improvement to management. Business process model is used to drive logical and consistent business flow as a reference model. Two examples for actual analysis of problems are offered.

Derivation of company-specific business flow
The procedure to use the business process model at the plant-site consists of two steps: 1. For a company-specific instance of the business process model, the business flow is rewritten by replacing the generic names of activities and information within the model with real-world activities undertaken in the company. 2. Brainstorming compares the current activities with the business flow. This can expose the problems of management framework as well as those of the activities themselves.
The business flow can be used to analyze various activities. From a safety viewpoint, two types of discussion are enabled: • Analysis of current activities, discussion of advanced countermeasures and precautionary action to prevent trouble/accidents, • Identification of root causes of trouble/accidents that have already occurred and discussion of countermeasures to prevent similar troubles/accidents.
With regard to the first view-point, inexplicit problems can be found by comparing current activities with the specific business flow for the individual company. For example, problems such as "activity of planning is not specified", "environment to share the process-safety information is not developed", "expert workers who have adequate skill for performing the activities are not assigned", can be clarified. Resulting safety countermeasures against them can be implemented preliminarily to prevent the troubles/accidents. With regard to the second view-point, root causes such as "problem on defect of information sharing", "insufficient operator training and improper assignment of personnel" can be identified and safety countermeasures against them can be implemented to prevent the recurrences of trouble/accidents. Fig. 13 shows an analysis based on a specific business flow. Specifically, the following points can be seen on it.
• Activities of PDCA cycle and resource provision are performed explicitly with the intents of follows; a) each role of activities of 'Plan ', 'Do', 'Check', 'Act' is clarified and performed certainly as well as the management framework of PDCA cycle is there, and b) provision of resources and information needed to perform the activities of 'Plan', 'Do', 'Check', 'Act' and management of engineering standard such as technical and management standards are performed.
• Contents of information transferring by performing activities such as the direction for planning and executing activities, the result of performing activities, including information on defect factors are sufficient.
• Necessary resource, information, and engineering standard are provided in the referable form when needed from the 'Provide resources' activity.
These ensure extraction of the problem on the contents of activity, the way information transfer ought to be, etc.

Analysis for operation problems
An example of the use of business process model for production from a safety point of view is application for operation problems in Fuji Oil Company, Ltd. It is well known that the root causes of operation failures due to human-error include misdirection, lack of communication and information sharing, poor education, lack of technical knowledge, and so on. Business process model for production is used to analyze these root causes of operation accidents that happened on the plant-site.
Business process model is used to clarify the activities that comprise the PDCA cycle and the activities of resource provision. The generic identification of activities and information in the model for production were replaced by the actual activities undertaken in the Fuji Oil Company and other related ICOM was added to develop the specific business flow as an instance of the business process model. Fig. 14 shows a business flow for 'Grade 3 LGOoperation'. The following points have been examined to identify the root causes of operation problems and to consider the countermeasures to be used in planning for prevention or recurrence.
• Each activity is performed according to engineering standards?
• ICOM is transferred with certainty? www.intechopen.com • Performance results of the 'Manage (Act) ', 'Plan', and 'Do' activities are evaluated at 'Check' activity?
• Workers are appropriately educated and/or trained?
• Resources including personal assignment were provided sufficiently?
• Other questions as shown in Fig. 13.
As results of them, advantages using business process model for case example have been reported as follows.
• Activities for safety management and/or quality management are not separated with usual manufacturing activities, but should be performed concurrently.
• Developed specific business flow clarifies the activities for 'Plan', 'Do', 'Check', and 'Act', and activity improvement based on it lead to implement certainly each activity which has been performed ambiguously in the past.
• It is understandable that the 'Provide resources' activity is very important and can lead to develop the environment of information sharing.
• Definition of activity based on the model can make the role of organization and human resources clear, and lead the integration or reformation of organization.
These advantages lead to development of the environment of a logical PSM system, including a production support system, a maintenance system, and so on. www.intechopen.com

Analysis for maintenance problems
The developed business process model for maintenance is an ideal model to maintain plantlifecycle safety. If the same mechanism as the model was used to perform maintenance, maintenance problems would not lead to accidents and/or disasters. Therefore, incidents related to maintenance would occur only if there were defects in the maintenance process.
To uncover such defects, cases of malfunctions have been followed backward through the ideal business process model.
The incident case to be followed here is:   The incident occurred at inspection of the block valve, so that the analysis is started from A54332 activity of Node-A5433. The information within Node-A5433 is as shown in Fig. 16(a). A54332 was carried out on the constraint of the directive from A54331, so that ICOM (1)-1 was incorrect directive. ICOM (8) included incorrect maintenance execution plan. A54331 had responsibility for safe sub-directive (ICOM (1)-1), and the responsibility should have been clarified in engineering standard; i.e. ICOM (2)-3 and ICOM (9). A54335 could not deliver sufficient engineering standard, and A54331 did not inform change request of www.intechopen.com (a) Summarized node-A5433.
(c) Summarized node-A543.   (7)). Therefore, the information described with heavy lines should have been incorrect, and the activities painted with gray ('Manage' and 'Provide resources') should have had error.
The Node-A5432 is almost same as Node-A5433 as shown in Fig. 16(b). The directive (ICOM (16)) from A5431 and the sub-directive ICOM-(10) from A54321 were incorrect. The ESs from A5435 (ICOM (17)) and from A54324 (ICOM-(11)-2) were incorrect. A54321 did not inform change request of maintenance execution plan to A5435 (ICOM (15)). The information described with heavy lines should have been incorrect, and the activities painted with gray ('Manage' and 'Provide resources') should have had error.
These analyses are continued up to Node-A0, and the results are as shown in Figs. 16(d) to (f). The information described with heavy lines should have been incorrect, and the activities painted with gray ('Manage' and 'Provide resources') should have had error.
This incident is categorized as problem of isolation, and is caused by the error in "A52 Make Production Plan" activity. However, it is obvious that it would be possible to prevent the incident, if the 'Manage' and 'Provide resources' activities are properly performed.

Conclusion
This chapter discussed a business process model of the Plant-LCE with the goal of creating an environment of logical disaster management. The importance of defining the business activities and information flow in the model as a reference model was described. The business process in the form of PDCA cycle throughout the plant-lifecycle as well as at each stage, and resource provision to share the process-safety information and to ensure consistency of engineering standard were also clarified.
Business process models developed for design, production, maintenance, and PSM were summarized. These models systematically showed the universal activities and information flow at each engineering stage. A logical and consistent business flow for each company can be developed by referring to these models. A specific business flow shows the framework, activity, information, etc. that are needed in order to prevent malfunctions and accidents and it is useful for the development of an environment for a systematic PSM. As a result, the number of accidents and hazards due to these defect factors will be reduced.
Further work is needed:

•
To consider the practicable business process model for ensuring consistency in engineering standard.

•
To consider the metrics for evaluating the result of activities at 'Check' stage.

•
To develop the framework of organization management based on the requirement of the framework of technical management which is represented in the business process model.

•
And cases studies should be undertaken to review and consider these issues. www.intechopen.com