See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/311709642

A Design of a Software System Supporting to Appropriately Perform the

Management of Change Procedure

Conference Paper · November 2016

CITATIONS READS

0 78

4 authors, including:

Kazuhiro Takeda Yukiyasu Shimada

Niigata University National Institute of Occupational Safety and Health JAPAN
68 PUBLICATIONS   140 CITATIONS    77 PUBLICATIONS   443 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Research for User Interface View project

Research for AI to diagnose an industrial plant safety View project

All content following this page was uploaded by Hirotsugu Minowa on 21 January 2017.

The user has requested enhancement of the downloaded file.

 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
1
Dept. of Business Administration, Okayama Shoka Univ., 2-10-1 Tsushima
Kyomachi, Kita-ku, Okayama, 700-0087, Japan
2
Center for Risk Management Research, Shizuoka University, 3-5-1 Johoku,
Naka-ku, Hamamatsu-shi, Shizuoka 432-8561, Japan
3
Chemical Safety Research Group, National Institute of Occupational Safety
and Health, Japan, 1-4-6 Umezono, Kiyose-shi, Tokyo 204-0024, Japan
4
Dept. 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 BPM-template for business process modelling

Enterprise Level E1 E2 E3 E4 E5
Announce corporate Make basic plan Perform Plant- Evaluate result of Provide resources
philosophy and for Plant-LCE LCE PSM Plant-LCE PSM for Plant-LCE
management policy PSM PSM
Site Level
A1 A2 A3 A4 A5 A6 A7
Manage Make Perform Perform Perform Provide human Provide
Plant-LCE execution process and construction manufacturing / organization resources for
plan for plant design resource for performing
Plant-LCE Plant-LCE Plant-LCE

A31 A32 A33 A34 A35 A36 A37 A41 A42 A43 A44 A45 A46
Perform Perform Perform Perform Perform
PSM PSM PSM PSM PSM
Manage Plan activities activities activities at Check P.R. Manage Plan activities at activities at Check P.R.
at R/D at design construction production maintenance
stage stage stage stage stage
Typical Typical Typical Typical Typical
tasks tasks tasks tasks tasks
(PDCA- (PDCA- (PDCA-PR) (PDCA-PR) (PDCA-PR)
PR) PR)

Fig. 2. Overview of PSM activities with Plant-LCE3

Fig. 3 Top activities for PSM with the Plant-LCE

 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.
Start
Step 1. Selecting Initial Activity
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 RIK?
No
Record
is because the ranges executing the process of MOC procedure Yes Reason
are wide such as maintenance and design change. After the above Processing on Change
execution, this phase shifts to Step 2．
Decidin
Yes
Step 2. Judgment of whether it is Replacement In Kind (RIK) or not g Next
Activity
If the transited destination activity coincides with a manage role
activity, as shown in Fig. 1, and is the first from the other No
hierarchical level, then its activity has the role to judge whether a End

request is RIK or not. This process corresponds to “Is it RIK?” in Fig. 3. Flow of
Fig. 3. RIK indicates whether or not the change is replacement of procedure
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

 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 Fig. 5. A window to record decision whether
to start process of MOC procedure the request on change is RIK or not

Fig. 6. A window to record changes on this Fig. 7. A window to select a next activity
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), 77–84 (1975).
2. Gould S. J. Chapter 8 Flixborough. Learning from Accident 3rd Edition (pp. 83–102). 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, 19–40 (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, 325–330 (2013).

View publication stats