5. Cross-Organization Process Re-engineering Method (COPReM)
5.4 Cross-organization Process Reengineering
5.4.2 Coupling Analysis
To obtain an accurate description of the information flow network, coupling relationships are employed to designate data exchange points between A/E and GC activities. Based on the input-operation-output paradigm, this study applies the coupling analysis method to identify the potential information flows between A/E and GC processes.
Identified information flows combine activities from different processes into a single, unified process in order to improve the global effectiveness of associated design and construction management processes.
Coupling relationships among the activities of different processes are determined by analyzing the similarity of input and output entities, as shown in Equation 5.13 shows. An activity Aik has a coupling relationship with activity Ajh, denoted by “
a
”, when the affinity of output data nr of Aikand input data n
s of Ajh exceed thresholdα (A(n
r, n
s) ≥ α ), where α
is set as 0.8.
ns
( , ) , ( ), ( )
nr
ik jh r s r ik s jh
A
aA
↔Na n n
≥α
∀ ∈n OUT A
∀ ∈n IN A
…….…..(5.13) where Aik represents the k th activity of process i; Ajh represents the hth activity of process j;nr represents the name of output data entity r of Aik; ns represents the name of input data entity “s” of Ajh; and α represents the similarity threshold, which, in this study, was set as 0.7. The notation
A
iknr aA
jhns means that the output data nr of Aik can be input data forA
jh due to the high level of similarity of nr and ns. In other words, data flow exists betweenA
ikand A
jh.Applying overlapping and coupling analyses, the cross-organization process reengineering procedure is constructed as shown in Figure 5.9. Firstly, overlapping analysis is used to merge similar processes and activities and update the original process models with merged ones. Data flow links can subsequently be recognized by referring to the updated processes. The final collaborative process model is established by summarizing the results of process mergence and activity collaboration.
Notations: m: No. of GC’s processes, n: No. of Professional Design’s Processes Figure 5.9 Process Integration Procedure.
Case study processes were analyzed and reengineered in accordance with the procedure illustrated in Figure 5.9. The threshold of FSim,
α , and the threshold of ISim, β,were respectively set as 0.45 and 0.5 to distinguish the proper reengineering method. In
this case, the overlapping relationship of P1 and P2 was defined as “Partial Overlapping”(ISim(P1
, P
2) = 0.546 ≧ 0.5, FSim(P
1, P
2) = 0.47 ≧ 0.46) and of P
1 and P3 as“Indefinite Overlapping” (ISim(P1
, P
3) = 0.58 ≧ 0.5, FSim(P
1, P
2) = 0.451 ＜ 0.46).
Therefore, “Activity Fusion” was the reengineering method recommended for P1 and P2
and either “Activity Fusion” or “As Usual” was the reengineering method recommended for P1 and P3. Upon considering the low similarity of P1 and P3 activities, the reengineering method recommended for the latter was “As Usual”. For P1 and P2, the high
FSim obtained was the result of the high similarity of ASim(DA2,DGC11) and ASim(DA2,DGC13) activities, as shown in Table 5.3. Therefore, two newly-fused activities,
namely “DM1. Determine preliminary subcontractor list” and “DM2. Qualified subcontractor selection” were created to replace the A/E “DA2. Preliminary coordinate”activity and the two GC activities, “DGC11. Collect subcontractor information” and
“DGC13. Register Qualified subcontractors”.
Coupling analysis was applied to determine data flow link(s) within the merged process model. As P1 and P2 activities had already been fused into a new process, only the coupling relationship between the new process and P3 needed to be determined. Equation 5.13 was used to identify eight coupling relationships, as shown in Table 5.6. Not all identified coupling relationships can be utilized because of potential coupling relationship conflicts. Using the example provided by coupling relationships in Table 5.6 the 3rd and 4th coupling relationships conflict with the other coupling relationships due to their sequential logic. Therefore, by applying the 1st, 2nd, 5th, 6th, 7th and 8th coupling relationships,
dataflow links from activity “DA4” to activity “DGC22” were determined and illustrated by the dotted line shown in Figure 5.10. The other dataflow links were identified in the same manner.
Table 5.6 Coupling Relationship in Case “A”
NO. Coupling Relationship Na value Conflict
1 D08.Detailed design drawings D18.Design drawings
DA4 DGC22
A a A
0.8 NO2 D08.Detailed design drawings D19.Purchasing specification
DA4 DGC22
A a A
0.8 NO3 D12.Results of detailed design D18.Design drawings
DA8 DGC22
A a A
0.8 Yes4 D12.Results of detailed design D19.Purchasing specification
DA8 DGC22
A a A
0.8 Yes5 D21.Inquiry sheet D10.Price comparing sheet
DGC23 DA7
A a A
0.8 NO6 D23.Price evaluation table D10.Price comparing sheet
DGC24 DA7
A a A
0.8 NO7 D22.Quotations D10.Price comparing sheet
DGC24 DA7
A a A
0.8 NO8 D24.Detail prices comparing list D10.Price comparing sheet
DGC25 DA7
A a A
0.8 NOFigure 5.10 the Overlapping/Coupling Relationship Diagram of Case “A” D07.Task control table of
detailed design
D07.Task control table of detailed design
information table DGC12. Preliminary
Qualifying
Detailed Design Process (P 1) Subcontractor Management Process
(P 2)
Tendering Process ( P 3)
Original Process of A/E Collaboration Area Original Process of GC Collaborative Detailed Design Process
Figure 5.11 the Collaborative Process of the D/B team in case study
According to the A/E and GC’s original eEPC diagram, the overlapping/coupling
relationships diagram as shown in Figure 5.10 can be transferred to the final collaborative design process. Figure 5.11 shows the final collaborative design process for the case study.
As the GC is designated in the case study as the D/B team leader, the GC must, under the new collaborative detailed design process model, complete requisite inquiries and price negotiations in order to provide the A/E with price and subcontractor information corresponding to each specific design item and, subsequently, fit design result specifications and price with GC subcontracting strategies. An experiment run to validate collaborative detailed design process model practicability showed, through interviews with senior engineers and managers, how the model could serve as an ideal prototype model for design collaboration between A/E and GC. However the global benefits derived from the collaborative process model must still be compared with ongoing performance studies of actual projects.
Chapter 6
Design-Build Process Collaboration System (DBPCS) Development
To implement the created collaborative process model, the design-build process collaboration system was developed according to the features of the collaborative process model.
Since the collaborative process model (CPM) was created based on the original A/E and GC processes, activities included in the model represent the regular work performed by A/E and GC. This infers that, in following the activity sequence in the model, staffs can achieve the collaborative process without changing their working behavior or loadings.
Therefore, the purpose of the D/B process collaboration system is the integration of activity actors to achieve activities with information sharing and communication functions rather than the automatic implementation of activities. Based on this concept, the DBPCS was developed following the Object-Oriented system development (OOSD) approach. The system analysis, system design and the system implementation are presented as follows:
6.1 System Analysis
The Design-Build Process Collaboration System (DBPCS) is the bottom layer of the IDBF which plays the infrastructure of IDBF to perform all collaborative processes embedded in DBMs. However, since the collaborative processes flow across two independent organizations, the data in the created collaborative processes is distributed over heterogeneous information environment. Therefore, the DBPCS not only can
automate the collaborative process model, but also needs the capability to exchange data between the legacy systems without interfering with original system functions.
Accordingly, the DBPCS must (1) proceed with the fast-tracking model and manage DBM execution procedures, (2) make CPM executable in the DBPCS, and (3) dispatch activities to corresponding actors and acquire information from the original information system in order to deliver consistent data to actors. Based on these basic requirements, the UML use case diagram was depicted to present the system requirements as shown in Figure 6.1.
Figure 6.1 Use Case Diagram of DBPCS
To accomplish these requirements in Figure 6.1, this research combines a Microsoft BizTalk framework and the Multi-Agent System (MAS) philosophy to develop the architecture of DBPCS as shown in Figure 6.2. Three function modules are included the DBPCS, namely, (1) a DBM management module, (2) the Process engine and (3) an activity execution module which respectively realized the “UC1”, “UC2” and “UC3” in the Figure 6.1.
Figure 6.2 The System Architecture of DBPCS
By cooperation between modules in Figure 6.2, the DBMs in the fast-tracking model can be implemented by DBPCS. The process engine is the core for module cooperation.
On the one hand, the process engine cooperates with DBM management module to invoke the specific collaborative processes of DBMs; on the other hand, the process engine cooperates with the activity execution module to implement the invoked collaborative processes.
For the collaboration between the process engine and DBM management module, the execution statuses of DBMs in the fast-tracking model will be update by DBM management module in accordance with the sequential relationships and the real-time process execution status. Subsequently, checking DBMs’ new statuses, DBM management module can invoke the specific collaborative processes of DBMs. Moreover, when a process is finished, the process engine will return a process finished message to DBM management module, so that DBM management module can update DBMs’ statuses and invoke new processes.
For the collaboration between the process engine and activity execution module, the process engine will invoke activities according to the activity sequence in the collaborative process model and send activity invoking messages to the activity execution module. As activity invoking messages retrieved, the activity execution module will implement the activities and return activity finished messages to process engine to trigger next activities.
Moreover, since the collaborative processes flow through A/E and GC’s organizations, activities of the collaborative process are distributed over departments of two companies.
Therefore, to implement the distributed activities, this study applied the multi-agent system (MAS) philosophy to develop the activity execution module due to the delegation, autonomy and distributed architecture characteristics of MAS. By collaboration of the software agents, the invoked activities can not only dispatch to the specific actors with consistent input data, but also actors can communicate with each other to complete activities. Summarily, the function requirements of DBPCS were listed as Table 6.1 shows.
Table 6.1 Function Requirements of DBPCS
No. Function Module Corresponding Requirements
(in use case diagram) Function Descriptions
1 Design Management
Module UC1. Invoke processes of DBMs
1. import DBMs data of the fast-tracking model and activity information of the collaborative process model to IDBF database 2. manage the IDBF database 3. update DBM execution status 4. invoke corresponding
collaborative processes of DBMs according to DBMs’
status
5. create invoking messages of the invoked processes
2 Process Engine UC2. Perform processes
1. manage invoked collaborative processes of DBMs
2. invoke activities of processes 3. create/send process finishing
messages while processes are completed
3 Activity Execution
Module UC3. Execute Activities
1. providing activity information 2. providing activity input data for
activity actors
3. assign tasks to activity actors 4. communicate activity actors
with messages
5. manage output data submitted by activity actors
6. retrieve external data if submitted output data is stored in legacy systems
6.2 System Design
6.2.1 DBM Management Module
The primary functions of DBM management module are managing the IDBF database and announcing the collaborative process invoking messages of DBMs. The DBM management module is composed of the IDBF database management UI, the DBM manager and the process monitor. The IDBF database management UI provides functions to manage the fast-tracking and collaborative process model information within a D/B project, and configure the system parameters of DBPCS. The IDBF database not only stores the DBM names and relationships in the fast-tracking model, but also records the
execution statuses during the system runtime. Therefore, the DBM manager can control the statuses of DBMs of a D/B project according to records within the IDBF database.
DBM Manager Process Monitor Process Message Queue Process Engine
Update DBMs status Invoke process: newly-invoke process set()
Check process invoking message()
process invoking message
Create process instance: process of DBMi() process invoked acknowledgement
Update DBMs status()
DBM Manager
Process Engine Process Message Queue Process Monitor
process finished messages
process invoking messages
Check process finishedmessage()
process finished message
finished process name
Update DBM status()
(a) invoke DBMs＇collaborative processes
(b) update DBMs＇statuses while processes are finished
Figure 6.3 Sequence Diagram of DBM Management Module
The Figure 6.3 shows the interaction relationships between the objects in DBM management module and the process engine. In Figure 6.3(a), after DBMs status are updated, the DBM manager will create a newly-invoked process set including all newly invoked processes of DBMs, and the process monitor will then generate process invoking messages, corresponding to processes in the newly-invoked process set, to be stored in the process message queue, so that the process engine can retrieve the invoking messages from message queue to create the corresponding process instances in the process engine. On the contrary (the condition in Figure 6.3(b)), when a process instance is completed, the process engine will generate the process finished message to process message queue. As process monitor received the process finished message, the execution status of the corresponding
DBM will be updated. Following these two recurring sequences, all DBMs in a D/B project can be invoked by the DBM management module.
6.2.1.1 DBM Manager
The function of DBM Manager is to update the DBMs’ statuses according to the overlapping relationships in the fast-tracking model as shown in Table 4.5. Therefore, according to the overlapping relationship between two DBMs, the sequence of their design and construction processes can be determined. Besides, a DBM has four types of status as shown in Table 6.2. To modify the DBMs’ statuses, this study applied the overlapping relationships to be the rules for determining whether the design and construction processes of a DBM can be invoked.
Table 6.2 Status of DBM
Status
No. Status Name Description
0 Not invoked The DBM is not invoked yet. The collaborative design process of this DBM can be invoked if the predecessors (DBMs) were all finished.
1 Design process invoked The collaborative design process is invoked. The DBM is in the design phase waiting for the process finished message of the collaborative design process.
2 Design process finished The collaborative design process has been finished, and the construction process can be invoked if the
predecessors (DBMs) were all finished.
3 Construction process invoked The construction process is invoked. The DBM is in the construction phase waiting for the construction finished message.
4 DBM finished Both collaborative design and construction process have bee completed. The DBM is finished.
The Figure 6.4 shows the process invoking algorithm of the DBM manager. Since all unfinished DBMs in the fast-tracking model need to be evaluated and updated by the algorithm, an unfinished DBM set will be created preliminarily to evaluate. For one evaluated DBM, the DBM manager will firstly check its current status. Only the DBM
whose design or construction process is not invoked needs to create its predecessor set subsequently (status No. is 0 or 2). The predecessor set is composed of the preceding DBMs of the evaluated DBM. If the evaluated DBM’s status No. is “0”, following the 4a procedure in Figure 6.4, the DBM manager can determine whether the design process of the evaluate DBM can be invoked by checking each preceding DBM’s status and the overlapping relationship between them. Meanwhile, if the evaluated DBM’s status No. is
“2”, the 4b procedure in Figure 6.4 will be applied to determine whether the construction process can be invoked. Therefore, processes of all DBMs can be invoked since DBM manager implements the process invoking algorithm continuously.
1. Create unfinished DBM set:
{DBMj | j=1~n}
2. Collaborative design or construction processes invoked ?
( Status(j)= 0 or 2 ? )
3. Create DBMj＇s predecessor set:
{DBMi| i=1~ m}
No
Yes
{DBMi} ≠ null ?
4a-1.Can collaborative design process of DBMj be invoked by DBMi?
4b-1. Can collaborative construction process of DBMj be invoked by DBMi?
4b-4. Create DBMj＇s successor set:
{DBMk| k=1~ s}
4b-5. Can Construction of DBMj be invoked by DBMk?
4b-8. Invoke Construction of DBMj
& modify status(j)=3 k = s ?
5. Refresh Design-Build Set {DBMj}
Yes
4. Collaborative design process invoked ? ( Status(j)= 0 ? )
6. Are all DBM finished?
(Status(j)=4 for all j)
DBMi: the predecessor of DBMj
DBMk: the successor of DBMj
Status(i) : status of DBMi
Status(j) : status of DBMj
Status(k) : status of DBMk
Figure 6.4 Process Invoking Algorithm of DBM Manager
To check if a collaborative process can be invoked or not, the process invoking rules are determined corresponding to each overlapping relationship in Table 4.5. The Figure 6.5 shows the process invoking rules for the “PP” overlapping relationship. For invoking the collaborative design process of DBMj, only the predecessor DBMi’s status is concerned, but for invoking the collaborative construction process of DBMj, the status of sucessor
DBMk needs to be concerned due to the feedback sequence of the “CCb” overlapping relationship.
Figure 6.5 Process Invoking Rules for “PP” Overlapping Relationship
6.2.1.2 Process Monitor
Creating process invoking messages and receiving process finished messages are two responsibilities of the process monitor. Firstly, the process monitor creates the process invoking messages to the process message queue according to the DBM’s invoking status determined by DBM manager. If the invoking status of the DBM’s design or construction process is true, the process monitor will create the corresponding process invoking message which is an XML-format message as shown in Figure 6.6(a). Secondly, when a process was finished, the finished message stored in the process message queue will be retrieved by process monitor. According to the finished messages, the process monitor can updates the specific DBMs’ statuses. Figure 6.6(b) shows the structure of process finished message.
Project ID DBM ID
Invoked Process DBM Name
Current DBM Status
Project ID
DBM Name Finished Date
Message Head: Process Type
Figure 6.6 Examples of Process Invoking/Finished Messages
6.2.2 Process Engine
The main responsibilities of the process engine are to automate all invoked processes and to cooperate with DBM management module and the activity execution module. On the one hand, by interacting with DBM management module through the process message queue, the process engine drives the invoked processes; on the other hand, in accordance with the activity information in collaborative process model, the process engine invokes the specific activities in the activity execution module through the activity message queue.
To drive processes, this study applied a Microsoft BizTalk server to develop the process engine. Based on the BizTalk server architecture, three default main objects; i.e., (1) BizTalk Server Application Host, (2) process instance and (3) BizTalk message box, are included in the process engine. Meanwhile, to facilitate communications with the DBM management module and the activity execution module, the process message queue and the activity message queues, are created additionally to be the intermediates between them.
Figure 6.7 shows the architecture of the process engine.
BizTalk Server
Control Flow DBM Management
Module Process
Monitor DBM
Manager
messages messages
Activity Message Queue Process Message Queue
Legend :
Figure 6.7 Architecture of Process Engine
BizTalk Server is a business process management application developed by Microsoft, which provides development tools and a runtime environment for workflow applications.
The BizTalk server runtime environment requires three primary components, including (1) the BizTalk server application host, (2) Process instances and (3) the BizTalk message box.
The BizTalk server application host is the object container of process instances (workflows) which provide the runtime environment for the invoked process. The process instance is a workflow object driven by the BizTalk server application host. This means that, for each invoked collaborative process, the BizTalk server application host creates a corresponding process instance to perform. As the collaborative process is invoked, the BizTalk application server host creates a process instance in the system memory according to
“BizTalk Orchestration”. BizTalk Orchestration is a workflow class for creating process instances in the BizTalk server. In this study, two orchestrations, (1) design orchestration and (2) construction orchestration, need to be developed respectively corresponding to the collaborative design and construction processes in the collaborative process model.
Therefore, all activities within the process model can be invoked and controlled by the BizTalk application server host. The orchestration consists of activities and their communication ports. The activity is responsible for data processing, and the
communication port is responsible for retrieving/sending necessary data from/to external
communication port is responsible for retrieving/sending necessary data from/to external