Conference PaperPDF Available

A Design of a Software System Supporting to Appropriately Perform the Management of Change Procedure

Authors:

Figures

Content may be subject to copyright.
A Design of a Software System Supporting to Appropriately Perform the
Management of Change Procedure
Hirotsugu Minowa 1*, Kazuhiro Takeda 2, Yukiyasu Shimada3, and Tetsuo Fuchino4
1Dept. of Business Administration, Okayama Shoka Univ., 2-10-1 Tsushima
Kyomachi, Kita-ku, Okayama, 700-0087, Japan
2Center for Risk Management Research, Shizuoka University, 3-5-1 Johoku,
Naka-ku, Hamamatsu-shi, Shizuoka 432-8561, Japan
3Chemical Safety Research Group, National Institute of Occupational Safety
and Health, Japan, 1-4-6 Umezono, Kiyose-shi, Tokyo 204-0024, Japan
4Dept. of Chem. Sci. and Eng., Tokyo Institute of Technology, 2-12-1 O-
okayama, Meguro-ku, Tokyo 152-8552, Japan
*E-mail: minowa@po.osu.ac.jp
Abstract
A change in criteria, procedure, and method of maintenance or design of chemical and nuclear
plants can have high associated risks, resulting in large-scale accidents. Therefore, a
management of change (MOC), which dictates managing change correctly when it comes to
criteria, procedure and method of maintenance or design, is important for life cycle
engineering. MOC is a type of business process management using business process model
(BPM). . The problem with executing an MOC is that it lacks explicit defined procedures and
sufficient time for execution. Such problems will result in accidents in the future.
To solve these problems, we propose a solution by using a software system to support the
execution of MOC procedure. Software support will be helpful as it can be used
anytime/anywhere. Our developing system supports operators to follow MOC procedure
correctly according to an rule defined as plant-life cycle engineering (Plant-LCE) based on
IDEF0 by controlling their execution, and sharing and updating the information of changes to
each administrator. This is expected to decrease operator’s loads and increase efficiency. This
study describes a support methodology by a software system based on BPM and Plant-LCE.
The results of the study show that it is advantageous and useful to implement a software
system, using an algorithm that supports MOC procedures. And shows a prototype software
incorporates our proposed idea.
1. Introduction
A change in criteria, procedure, and method of maintenance, or design of large-scale plants
such as chemical and nuclear plants can have high associated risks, resulting in large-scale
accidents. Therefore, a management of change (MOC), which dictates managing change
correctly when it comes to criteria, procedure, method of maintenance, or design, is important.
There was an accident that was caused by a flawed MOC procedure, which resulted in a vapor
cloud explosion at a chemical plant, owned by Nypro, in Flixborough1-2 (England), on 1 June
1974; the accident killed 28 inhabitants and injured 53. The direct cause of the accident was
the shear failure, which was caused by the use of a bent valve to connect two reactors.
However, the root cause behind the accident was that such a problem was not clearly defined
in the MOC procedure. Incorrect execution of MOC can result in some accidents. The causes
of the failure are, for example, the insufficient sharing information of change or the neglected
or insufficient rule of preventing appropriate MOC procedures. MOC is important for
sustainable engineering when it comes to industrial plant administration.
The Safety Division in the Society of Chemical Engineers, Japan, discusses the management
model of MOC procedure based on Integrated DEFinition Methods 0 (IDEF0) by considering
the importance of MOC in the study of process safety management (PSM)3. The results of this
research led to an advanced research that realized a software program to support MOC
execution. This study describes a support methodology using a software system for a business
process model (BPM). The results of the study show that it is advantageous and useful to
implement a software system, using the proposed algorithm that supports MOC procedures.
And shows a prototype software incorporates our proposed idea.
2. Conventional Works
2.1. MOC Process Modeling
Our authors who join the Safety Division in the Society of Chemical Engineers, Japan
developed a BPM in plant-life cycle engineering (Plant-LCE) using IDEF0. The model is
based on PDCA (Plan, Do, Check, Action) cycle. Fig. 1 shows a template of the basic cycle of
the model.
Fig. 1. Template for business process model3
Fig. 2. Overview of PSM activities with Plant-LCE3
612 Journal of Chemical Engineering of Japan
is BPM-template enables the development of a busi-
ness process model to perform activity planning, execution,
evaluation, and improvement. at is, the model based on
the proposed BPM-template shows the implementation in
the form of PDCA-cycle and the uniform management of
engineering standard (ES) with the provision of just enough
resources. Furthermore, the developed model can clarify
the purpose, the contents, and the relevant information of
individual engineering activity. Activities that are performed
at actual companies (plant engineering companies, plant op-
eration companies, etc.) have been compiled and examined,
and business process models have been developed based on
the BPM-template.
3.2Business process model for PSM with the Plant-LCE
e main purpose of PSM is to maintain the safety of a
Fig. 2BPM-template for business process modelling
Fig. 3Top activities for PSM with the Plant-LCE
Announce corporate
philosophy and
management policy
E1
Make basic plan
for Plant-LCE
PSM
E2
Perform Plant-
LCE PSM
E3
Evaluate result of
Plant-LCE P SM
Provide resources
for Plant-LCE
PSM
E5
Manage
Plant-LCE
Make
execution
plan for
Plant-LCE
Perform
process and
plant design
Perform
construction
Perform
manufacturing
Provide human
/ organization
resource for
Plant-LCE
Provide
resources for
performing
Plant-LCE
A2
A3
A5
A6
Manage
Plan
Perform
PSM
activities
at R/D
stage
Perform
PSM
activities
at design
stage
Perform
PSM
activities at
construction
stage
Check
P.R.
A31
A32
A33
A35
A36
A37
Enterprise Level
Site Level
Manage
Plan
Perform
PSM
activities at
maintenance
stage
Check
P.R.
Perform
PSM
activities at
production
stage
A42
A43
A45
A44
A46
Typical
tasks
(PDCA-
PR)
Typical
tasks
(PDCA-
PR)
Typical
tasks
(PDCA-PR)
Typical
tasks
(PDCA-PR)
Typical
tasks
(PDCA-PR)
Fig. 1 shows that the template for BPM has a Provide Resources (PR) activity3 that provides
necessary resources to support and control PDCA 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 PDCA activities, d) information for
progress management, and e) engineering standard (ex. Technical standard and control
standards) for controlling each activity that are distributed from the upper level. Shimada at el.
developed the Plant-LCE based on the template for BPM.
The basic model3 for BPM is shown in Fig. 2. The details of the model will be more and
more elaborate in the future. However, the defined procedures will be more complex. The
complexity makes it difficult for the operator to correctly follow the procedure of the model.
If this problem is not solved, it is difficult to guarantee safety as the workers will not be able
to execute the BPM correctly.
3. Research
3.1. Methodology
This section describes the research direction. Our research aims to support the execution of
MOC procedure in PSM. Therefore, a computer-aided solution using software technology
was implemented to solve problems mentioned in 2.1. The problems and ideas to solve by
software are mentioned in 3.2.
3.2. Problem and computer-aided solution idea
There are problems on complexity that the operator executes along with the procedure on
BPM include MOC. Therefore, the execution of procedure is required to be improved, as
mentioned in the latter of 2.1. This section explains the problems and the proposed solutions
by realizing the computer-aided execution of MOC using software support.
i. Realize support to execute the MOC procedure correctly
Authors proposed a PSM that is a BPM for safety based on PDCA cycle, as shown in Fig.
1. MOC procedure is a part of PSM and it is also required to follow the management based
on PDCA cycle3. However, the execution procedure becomes huge and complex because
MOC procedure has a lot of changes in the agenda that needs to be discussed such as
aptitude test and substitute of device parts, materials, and procedures.
The problem is solved via computer-aided systems because the computer can record
massive knowledge and data correctly and support user’s requests anytime/anywhere. For
example, a computer restricts manipulation and provides inputs for the user in order to
follow the defined procedures, and it can also check the validation of the inputted contents.
ii. Sharing/updating of information
Sharing/updating of information is very important. The lack of sharing information
results in the required information not being delivered to the operator even though the
required information exists. The inadequate updating of information results in the access
of old information that is not the latest version. Such wrong information can be an
indirect cause of accidents. These mistakes may finally cause accidents as a result of poor
documentation of MOC procedures.
However, using computer-aided systems may solve the lack of information issue.
Recently, computers have been evolving and growing, especially over the network. For
example, e-mails, content management systems, and message/audio/video chats make it
easier to share information. The details of updating are described below:
iii. Updating of information: version management of information
The updating of information is necessary for long-term engineering, as mentioned in 3.
The updating of information is an action that helps in maintaining the latest information.
This is called versioning information. The problem with versioning is that it is difficult to
maintain consistency. For example, using conventional file management applications
such as Microsoft Word or Excel, it is possible to manage information; however, a little
mistake in information can lead to an error. Therefore, that conventional method is also
difficult to follow rules completely.
The solution for the above problem is the creation of a mechanism that facilitates
updating information. For example, let us consider a mechanism that allows recording the
description of change into subdivided fields. This mechanism is burdensome for the
operator, and therefore computer-aided support is required to efficiently record data that
the operator has entered. For example, a mechanism of version management that manages
information with every updated version. The version management system can manage the
source code efficiently in the software development world. The diversion of this
technology is useful to this problem.
iv. Support of root cause analysis (backward trace)
If an accident occurs after the execution of MOC procedure, it is necessary to
investigate its causes in detail in order to analyze the recorded log in the MOC procedure
and remove its cause from the log for improvement. Then, the investigation visualizes
and analyzes the executed sequence of MOC procedure from the recorded log. This
analysis is called as backward trace and it makes it easy to find the cause, search the
subjects, and evaluate the validation. The software-implemented backward trace
mechanism will decrease the analytical load of the analyzer since the software technology
is good at recording, tracing, and visualizing using graphs.
3.3. Proposed MOC procedure
This section reports a proposed procedure, that is an algorithm, defined to realize the aim
described in section 3.2 (i). The feature is that Plant-LCE controls execution order of MOC
procedure This indicates that the system has flexibility to change MOC by depending on
situation, site, purpose etc. The process flow which followed Plant-LCE on MOC procedure is
described in below, and that summary shown in Fig. 3.
Step 1. Selecting Initial Activity
Select an initial activity to start the process of MOC procedure
from the Plant-LCE. The reason that any activity can be selected
is because the ranges executing the process of MOC procedure
are wide such as maintenance and design change. After the above
execution, this phase shifts to Step 2
Step 2. Judgment of whether it is Replacement In Kind (RIK) or not
If the transited destination activity coincides with a manage role
activity, as shown in Fig. 1, and is the first from the other
hierarchical level, then its activity has the role to judge whether a
request is RIK or not. This process corresponds to “Is it RIK?” in
Fig. 3. RIK indicates whether or not the change is replacement of
the same kind. If the current activity does not coincide with RIK, then the reason is
recorded as “not RIK” and this phase shifts to Step 4. Otherwise this phase shifts to Step 3.
Step 3. Processing on change
Fig. 3. Flow of
procedure
Start
Selecting Initial Activity
Is RIK?
End
Processing on Change
Decidin
g Next
Activity
No
Yes
No
Yes
Record
Reason
Process the changes such as discussion, information update etc., corresponding to the
request of current activity. After the above execution, this phase shifts to Step 4
Step 4. Deciding an activity of next transition destination
Deciding whether this execution completes or the transition that the current activity shifts
to a next destination activity on Plant-LCE, as shown in Fig. 2. This phase shifts to Step 2
when there is no requirement to discuss, study, and change, and the current activity is
located in the same hierarchical level of the initial activity on Plant-LCE.
4. Evaluation
This section reports the results of the evaluation of our proposed method mentioned in 3.3.
The target is a case4 where a worker changed the amount of flow corresponds to a minimum
in a gasoline desulfurization unit that removed the sulfur component in residual gasoline; this
gasoline was produced from a fluid catalytic cracking (FCC) device. Although the detailed
results of the analysis are omitted because of space constraints, our proposed method
concluded that it has no problems in guiding the MOC procedure to a worker because our
procedure was coincided with the procedure which an expert executed.
5. Implementation
We developed a prototype software for operators to easily and correctly follow the
procedure in 3.3 for the purpose of solving the problems mentioned in 3.2.
5.1. Prototype software
This section explains the developed software and how it supports the operator to execute
the MOC procedure. The details are described below:
Step i. Selecting initial activity
This phase corresponds to Step 1: Selecting an initial activity to start MOC procedure.
A window of this software system, as shown in , allows operators to select the initial
activity from a tree view UI (upper on window). The data of hierarchical activities are stored
in and loaded from an XML file. If a user selects an activity, its detail is shown in the lower
part of . After the above execution, this phase shifts to Step ii. *表題:title, 説明: description.
Step ii. Deciding whether it is RIK or not
This phase corresponds to Step 2: Deciding whether the changes correspond to RIK or not.
If a request on the change corresponds to RIK, the operator needs to insert a check into a
check box at the bottom 同種の変形,” as shown in : And to describe the reason on that
decision as log into a text box. After the above execution, this phase shifts to Step iii.
Step iii. Recording changes
This phase corresponds to Step 3: Recording changes as log. The operator records changes
in the current activity to a column (is “変更管理”), as shown in Fig. 6. After the above
execution, this phase shifts to Step iv.
Step iv. Selecting a next activity
This phase is corresponds to Step 4: Describing the transitional reason to each destination
activity, and shifting to a selected activity in Fig. 7. The reason for recording the transitional
reason is because the transitional reasons are necessary for the backward trace. After the
above execution, this phase shifts back to Step ii, that is, if this process does not terminate.
Fig. 4. A window to select an initial activity
to start process of MOC procedure
Fig. 5. A window to record decision whether
the request on change is RIK or not
Fig. 6. A window to record changes on this
activity
Fig. 7. A window to select a next activity
6. Conclusion
This paper reported results of our method to support the execution of BPM by software
development. The results of the study shows that it is advantageous and useful to implement a
software system, using an algorithm that supports MOC procedures. And shows the prototype
software incorporates our proposed ideas. In the future, the authors will evaluate the support
performance of our software in some other case study.
Acknowledgements
This work was supported by JSPS KAKENHI Grant Number JP26350469.
References
1. Warner, S. F. The Flixborough Disaster. Chemical Engineering Progress, 71(9), 7784 (1975).
2. Gould S. J. Chapter 8 Flixborough. Learning from Accident 3rd Edition (pp. 83102). Gulf
Professional Publishing (2008).
3. Shimada, Y., Kitajima, T., Fuchino, T., & Takeda, K.. Disaster Management Based on Business
Process Model Through the Plant Lifecycle. Approaches to Managing Disaster - Assessing
Hazards Emergencies and Disaster Impacts, 1940 (2008).
4. Takeda, K., Saito, H., Shimada, Y., Kitajima, T., Fuchino, T., & Naka, Y.. Analysis of Business
Flow of MOC based on Business Process Model of Plant Lifecycle Engineering. Chemical
Engineering Transaction, 31, 325330 (2013).
ResearchGate has not been able to resolve any citations for this publication.
Full-text available
Conference Paper
Management of change (MOC) has been a very important issue in process safety management. Individual change management is an instance of the plant lifecycle engineering (Plant-LCE), however a business flow of MOC has been hardly discussed. Engineering over the plant lifecycle is called Plant-LCE. On the other hand, the logical process safety management based on the business process model (BPM) for Plant-LCE has been proposed. In this study, the business flow of the MOC based on the BPM for Plant-LCE is analysed. To demonstrate the analysis of the business flow of the MOC, an example of MOC of minimum feed rate of a plant was traced in the BPM for Plant-LCE.
Full-text available
Chapter
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 processesand 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.
Disaster Management Based on Business Process Model Through the Plant Lifecycle. Approaches to Managing Disaster -Assessing Hazards Emergencies and Disaster Impacts
  • Y Shimada
  • T Kitajima
  • T Fuchino
  • K Takeda
Shimada, Y., Kitajima, T., Fuchino, T., & Takeda, K.. Disaster Management Based on Business Process Model Through the Plant Lifecycle. Approaches to Managing Disaster -Assessing Hazards Emergencies and Disaster Impacts, 19–40 (2008).
  • S J Gould
  • Chapter
Gould S. J. Chapter 8 Flixborough. Learning from Accident 3rd Edition (pp. 83-102). Gulf Professional Publishing (2008).
The Flixborough Disaster
  • S F Warner
Warner, S. F. The Flixborough Disaster. Chemical Engineering Progress, 71(9), 77-84 (1975).
Analysis of Business Flow of MOC based on Business Process Model of Plant Lifecycle Engineering
  • K Takeda
  • H Saito
  • Y Shimada
  • T Kitajima
  • T Fuchino
  • Y Naka
Takeda, K., Saito, H., Shimada, Y., Kitajima, T., Fuchino, T., & Naka, Y.. Analysis of Business Flow of MOC based on Business Process Model of Plant Lifecycle Engineering. Chemical Engineering Transaction, 31, 325-330 (2013).