DOI: 10.3303/CET2290053 Paper Received: 29 January 2022; Revised: 3 March 2022; Accepted: 17 April 2022 Please cite this article as: Takeda K., Fuchino T., Kitajima T., Shimada Y., Iuchi K., Saito H., 2022, A study of required information for risk assessment in management of change based on business process model, Chemical Engineering Transactions, 90, 313-318 DOI:10.3303/CET2290053 CHEMICAL ENGINEERING TRANSACTIONS VOL. 90, 2022 A publication of The Italian Association of Chemical Engineering Online at www.cetjournal.it Guest Editors: Aleš Bernatík, Bruno Fabiano Copyright © 2022, AIDIC Servizi S.r.l. ISBN 978-88-95608-88-4; ISSN 2283-9216 A Study of Required Information for Risk Assessment in Management of Change Based on Business Process Model Kazuhiro Takedaa*, Tetsuo Fuchinob, Teiji Kitajimac, Yukiyasu Shimadad, Kensuke Iuchie, Hideo Saitof a Shizuoka University , Hamamatsu, Japan b Tokyo Institute of Technology , Tokyo, Japan c Tokyo University of Agriculture and Technology , Tokyo, Japan d National Institute of Occupational Safety and Health , Tokyo, Japan e Safety Case Laboratory, Chiba, Japan f Saito MOT Laboratory, Chiba, Japan takeda.kazuhiro@shizuoka.ac.jp To prevent accidents caused by change management faults, it is necessary to correctly determine whether the requested changes are of the same kind, and if it is determined that they are not of the same kind, correctly evaluate the risks before and after the change. These judgments and evaluations cannot be correctly performed without reference to the design rationale and change history. Therefore, in this paper, we propose a causal relationship model as an expression method that explicit the design rationale information. By expressing with the proposed model, design rationale information can be spiraled up throughout the plant life cycle and accumulated as part of digitalization. For the case of determining whether the change requests are of the same kind based on the causal relationship model, the design rationale information can be referred to, and items that are usually difficult to note can be examined. 1. Introduction Accidents have been continuously caused by the poor management of change (MOC) in chemical plants. Piong summarized that 9.1% of chemical process accidents is caused by the MOC failure (Piong 2017). CCPS said the MOC should be properly managed to prevent accidents (CCPS, 2008). In order to prevent accidents caused by change management faults, it is necessary to correctly determine whether the requested changes are of the same kind, and if it is determined that they are not of the same kind, correctly evaluate the risks before and after the change. These judgments and evaluations cannot be correctly performed without reference to the design rationale and change history. However, because design rationale information depends on people and is implicit, it is difficult to retrieve the information when needed, and it is lost as people move. Therefore, in this paper, we propose a causal relationship model as an expression method that explicit the design rationale information. By expressing with the proposed model, design rationale information can be spiraled up throughout the plant life cycle and accumulated as part of digitalization. 2. Proposed model 2.1 Business process model for plant life-cycle engineering MOC in a chemical plant is a business process that spans the entire life cycle (development, design, construction, operation, maintenance, and disposal). Therefore, in order to properly perform the MOC, it is desirable that the business process of the life cycle by fully revealed. The integrated definition for a functional model standard, type-zero (IDEF0) is a notation for describing the business processes (NIST, 1993). In IDEF0 notation, activity is represented by a box and information exchange is represented by arrows. The arrows connected to the box consist of four types, i.e., input, output, control, and mechanism. The business is expanded into sub-businesses. However, IDEF0 has a high degree of freedom, and the expression method 313 tends to fluctuate depending on the writer. Furthermore, since the engineering business process of the entire life cycle is complex, the expressions should be aligned as much as possible by describing based on a template (Fuchino et al., 2010). Figure 1 shows the template proposed by Fuchino et al. (2010). The template explicitly represents the PDCA cycle for spiraling up engineering. Furthermore, it consists of an activity that provide resources to each PDCA activity. As shown in Figure 2, based on the template, an engineering business process model for the entire life cycle of a chemical plant has been proposed (Shimada et al., 2012a, 2012b). Figure 1: Template of business process model Figure 2: Business process model of plant lifecycle engineering 2.2 Management of change The MOC is a business process that spans the entire life cycle of the chemical plant. Changes are mainly requested from the operation and maintenance activity and are considered in the development and design activity. It is first determined whether it is a replacement in kind (RIK). If it is an RIK, perform the replacement. If is not in an RIK, assess the risk before and after the change. If the risk after the change is lower than the risk before the change, the design is changed, and modification is done. Also, after the change, the changed operation and maintenance activities will be performed at the plant. In this way, the MOC is a business process that spans the entire life cycle, so it is difficult to correctly execute the MOC. Therefore, a method of executing the MOC based on the business process model of the plant life-cycle engineering has been 1 Manage 2 Plan 3 Do 5 Provide Resources 4 Evaluate Axyz Upper Activity A1 Manage Plant- LCE A3 Perform process and plant design A4 Perform construction A5 Perform manufacturing A7 Provide Resources for performing Plant-LCE A2 Make execution plan for Plant- LCE A0 Perform Plant- LCE Ｎｏｄｅ-A0 From A341 To A341 To A348 A51 Manage manufacturing A52 Make plan for manufacturing A53 Perform production A54 Perform maintenance A56 Provide Resources for performing manufacturing Ｎｏｄｅ-A5 A31 Manage process and plant design A33 Perform conceptual process design A34 Perform preliminary process design A35 Perform detail process design A39 Provide resources for process and plant design A32 Decide concept for process and plant design A36 Perform preliminary plant design A37 Perform detail plant design From A531 To A531 To A537 From A541 To A541 To A545 Ｎｏｄｅ-A3 314 proposed (Takeda et al. 2013). This paper proposes a methodology for the MOC as a business process but does not mention the information handled by the MOC. Therefore, in this paper, we refer to the information used for risk assessment in the MOC (especially, the judgment of the RIK or not). Consider the case of determining whether it is the RIK in the MOC. Even if the same parts are manufactured by the same manufacturer during the same period, they are not exactly the same because there are individual differences. However, if they have exactly the same functions, they can be said to be the same kind. However, it is rare that they have exactly the same function. When they are within a certain designed allowable range, they are considered to be almost the same kind. If it is within the designed allowable range, we would like to allow it to be the same kind. However, even if it is individually within the designed allowable range, it cannot be said that there is no problem with all combinations of the upper limit and the lower limit. In this way, it is insufficient to make a judgment only within the superficial designed allowable range. It is considered that it cannot be judged to be of the same type unless it is compared with the design intention behind it. In the next section, the relationship between the design intention and the designed plant will be described. 2.3 Intention, process action, operation, and equipment requirement ANSI / ISA-S88 (1995) proposes three models, i.e., the process action, procedural elements, and equipment. Although this standard is intended for batch processes, it provides important implications for all processes, not just batch processes. The relationship between the three models is that process action is designed, and operations as procedural elements and equipment are designed to realize the designed process action. The process action should be designed based on some design rationale. Fuchino et al. (2004) introduced intention as a design rationale as shown in Figure 3. To determine whether the change is an RIK, it should be determined not by whether it meets the requirements designed as a process action, but by whether it originally meets the intention. Figure 3: Relationship between intention, process action, operation, and equipment requirement 2.4 Cause effect relationship In this paper, we propose a causal relationship model as a method of expressing intention. In the causal relationship model, among the causal relationships between the state variables of a process, those that lead to undesired consequences are represented by nodes and their causal relationships by arrows. However, in the control system, the devices of the control system and their failure events are also expressed as nodes because they are factors that change the state in addition to the state propagation. Event nodes are represented by boxes, and other state nodes and device nodes are represented by circles. Figure 4 shows an example of a causal relationship model. The state propagates according to the arrow, and in the control system, the abnormal state propagates depending on the device of the control system and its failure mode. One of the roles of the control system as safety instrumentation is to suppress the propagation of the abnormal state, but here it is assumed that the propagation of the abnormal state cannot be suppressed or that the response is reversed. The causal relationship model expresses the intention of the process, not the causal relationship of all the state variables in the process. It is postulated that a process is designed with the intention of putting the process in the desired state or preventing the process trending from the desired state. In other words, there is Process Cell(s) Requirement Unit(s) Requirement Unit(s) Requirement Equipment Requirement is an o rdered set of is an ordered set of Process Process Operation Process Stage Process Action is an ordered set of is an ordered set of Procedure(s) Unit Procedure(s) Operation(s) Operation (Procedure) is an ordered set of i s an ordered set of S afety Q uality C ost D elivery Intention ( SQCD ) needs to perform needs to perform needs to perform needs to perform needs to perform needs to perform 315 intention expressed by a causal relationship model in the background of process design decision making. Therefore, the causal relationship model can be explicit design rationale information. In general, design rationale information is people dependent implicit knowledge. It is difficult to refer to design rationale information because it is implicit, and knowledge is lost as the people move because it depends on the people. Also, as implicit information that people have, undesired consequences and state transitions leading to them may appear, but what and how they were designed to prevent them do not appear. On the other hand, when the design rationale information is explicit and accumulated by the causal relationship model, the knowledge can be accumulated as an organization. Figure 4: Causal relationship model In addition, when determining whether it is an RIK, it is possible to determine whether it is of the same kind by referring to the design rationale by examining whether the assumed state is changed by referring to the causal relationship model. By searching for the items to be examined using the causal relationship model, the items can be comprehensively listed. However, depending on the item, a quantitative assessment may be required. The critical parameter referred to in the quantitative assessment can refer to the design rationale by the proposed causal relationship model. As shown in Figure 5, the proposed causal relationship model is generated by the development activity (Fuchino et al., 2018). At the time of design, there are the stages of conceptual design, basic design, and detailed design, and a process hazard analysis (PHA) is executed in each stage. Commonly used methods, such as HAZOP and LOPA, are used for the PHA in the detailed design stage. The PHA can refer to the causal relationship model generated in development activity. The causal relationship model is also modified or updated by the PHA at each stage. The PHA results are referred to in the operation or maintenance activity, while the causal relationship model is referred to in the operation, maintenance, or disposal activity as design rationale information. In addition, the development and design activities will be performed again in response to change requests from the operation or maintenance activity. Every time the development and design activities are performed, the causal relationship model is modified or updated by the receiving operation or maintenance information. In the causal relationship model as design rationale information, the knowledge as rationale information spirals up during the life cycle through the business process of the MOC. As the spiral rises, knowledge accumulates, and the causal relationship model becomes huge. When using a causal relationship model, do not refer to all of them, but extract and use only the relevant causal relationships as needed. Figure 5: Causal relationship model, HAZOP, and LOPA in plant lifecycle 316 3. Simulation This section shows the results of the enumeration of the examination items and quantitative assessment for determining whether the RIK is performed using a causal relationship model for the MOC of the example process. 3.1 Objective process The objective process is shown in Figure 6. In the objective process, the intermediate from the hydrodesulfurization (HDS) unit is reformed using the selective hydrogenation unit (SHU), then separated into off gas, LPG, and gasoline in a distillation column. Before entering the SHU reactor, the intermediate is controlled along with the oil to hydrogen ratio and preheated three times. The change request is a decrease in the minimum inflow rate to the SHU reactor. Figure 6: Process Flow Diagram of objective process 3.2 Cause-Effect relationship for objective process Figure 7 shows the causal relationship model of the objective process. In this figure, among the causal relationships, only the causal relationships that lead to a runaway reaction as the most undesired consequence when the minimum flow rate of the SHU reactor is lowered are shown. The causal relationship is assumed when the flow rate decreases as shown by the red line. Figure 7: Causal relationship model of runaway reaction of objective process 317 3.3 Check point for management of change The evaluated items extracted from the above-mentioned causal relationship model are shown below.  Reaction in the SHU due to reduced flow rate: The influence of the fluctuation on the product composition was low.  Distillation for reactant fluctuations: The effect of the fluctuating on the product composition after distillation was low.  Preheating before the SHU: the phase change does not occur, because of verifying whether the phase change inside the heat exchanger may occur due to the decrease in the flow rate.  Hydrogen flow rate control valve for hydrogen/oil ratio control: The CV value of the valve was within the appropriate range. It was confirmed that the change request in the objective process was within the expected range of the design intention by examining the items extracted from the causal relationship model. Therefore, it can be said that this change request was the RIK. In the above examination, it was possible to examine even the CV value of the hydrogen flow rate control valve, which is usually difficult to determine. Therefore, it was possible to examine whether it is the same kind referring to the design rationale based on the causal relationship model, and the effectiveness of this proposal could be demonstrated. 4. Conclusions Based on business process model of plant life-cycle engineering, we proposed a causal relationship model as an expression method for risk assessment of the MOC by referring to the design rationale information. Since the MOC is an engineering business process throughout the plant life cycle, it was based on the business process model of the entire plant life cycle. Since it is necessary to compare the design rationale of the process to determine whether the changes are of the same kind, we proposed a causal relationship model as a method of expressing the intention as the design rationale of the process. The proposed model makes it possible to explicit the implicit and people-dependent design rationale information and accumulate it as knowledge. In an MOC example case, it was determined whether the change request was an RIK based on the causal relationship model. It was even possible to study the CV value of the hydrogen flow rate control valve, which is usually difficult to notice, and to verify the effectiveness of the proposed causal relationship model. In the future, we will establish a method for creating a causal relationship model with the aim to build an engineering support environment based on the causal relationship model. References CCPS, 2008, Guidelines for the Management of Change for Process Safety, Wiley Fuchino, T., 2004, Seihin Kaihatsu To Recipe, Batch Process Engineering, Maki Shoten Fuchino,T.; Shimada,Y.; Kitajima,T. & Naka,Y. (2010). Management of Engineering Standards for Plant Maintenance based on Business Process Model, Proceedings of 20th European Symposium on Computer Aided Process Engineering, ESCAPE-20, Elsevier, pp.1363-1368, ISBN 978-0-444-53569-6, Ischia, Italy, June 6 - 9 Fuchino T., Kitajimab T., and Shimada Y., 2018, Representation of Process Design Rationale for Change Management, Probabilistic Safety Assessment and Management (PSAM) 14 NIST, 1993, Draft Federal Information Processing Standards Publication 183 Piong, H. S., et al., 2017, The Contribution of Management of Change to Process Safety Accident in the Chemical Process Industry, Chemical Engineering Transactions, 56, pp.1363-1368 Shimada Y., 2012a, Development of Environment for Logical Process Safety Management based on the Business Process Model, J or Chemical Engineering of Japan, 45, 4, pp.245-257 Shimada Y., Kitajima T., Fuchino T. and Takeda K., 2012b, Disaster Management Based on Business Process Model Through the Plant Lifecycle, Approaches to Managing Disaster - Assessing Hazards, Emergencies and Disaster Impacts, InTech, pp.19-40 Takeda, T., Saito H., Shimada Y., Kitajima T., Fuchino T. and Naka Y., 2013, Analysis of Business Flow of MOC based on Business Process Model of Plant Lifecycle Engineering, Chemical Engineering Transactions, 31, pp.325-330 318 lp-2022-abstract-050.pdf A Study of Required Information for Risk Assessment in Management of Change Based on Business Process Model