final phd was

Hardly any construction project goes totally as planned, as relatively high uncertainty exists in the planning phase of a construction project. Consequently, management plans often have to be changed to suit the new project conditions. The uncertainty can be evalu-ated as potential causes of risks and risks can be in turn evaluated as potential causes of changes in the project plans.

Using concepts from the Business Process Modeling domain, the uncertainty in the pro-cess schedule is modeled as configurable fragments in the reference process model. The configuration trigger of each configurable fragment is a risk event with (ON/OFF) status. According to the status, structural changes will be caused to the model by either the inclusion or the exclusion of one or more configurable fragments. These configurable fragments are described on type level as Configuration Templates. The procedures in the background of the Configuration Templates can be used to carry out the needed structural changes more quickly than making them manually as usual.

In view of that, a schema of a Configurable Reference Process Model (CRPM), that con-tains all known process knowledge in the form of essential and configurable process fragments, is introduced. For the management of the CRPM-lifecycle an IT-System-ar-chitecture is suggested in this work to support the design, the implementation, and the enhancement of the CRPMs.

The approach presented in this dissertation helps to speed up the planning process and to ensure getting more reliable process schedule plans. Moreover, it accelerates the adap-tability of the changed schedule plans by offering readily integrable solutions for recurring problems.

This CRPM-based approach is suggested as a guidance that can support the work of the planner and not as a restriction to his individual ideas or a replacement to his experience.

ISBN 978-3-86780-228-4© 2011 W

AEL

SH

AR

MA

K

· D

YNA

MIC

NET

WO

RK

PLA

NN

ING

IN C

ON

STR

UCT

ION

PR

OJE

CTS

USI

NG

CO

NFI

GU

RA

BLE

REF

EREN

CE

PR

OC

ESS

MO

DEL

S

Wael Sharmak

Dynamic Network Planning inConstruction Projects usingConfigurable Reference Process Models

DISSERTATION · FAKULTÄT BAUINGENIEURWESEN

Berichte des Instituts für Bauinformatik · Heft 99

TUD

· B

AU

INFO

RM

ATIK

Diese Arbeit wurde unter dem Titel

Dynamic Network Planning in Construction Projects using Configurable Reference Process Models Dynamische Netzplanung in Bauprojekten unter Verwendung von konfigurierbaren Referenzprozessmodellen an der Fakultät Bauingenieurwesen der Technischen Universität Dresden als DISSERTATION Von Wael Sharmak geboren am 20. Juli 1977 in Damassuburb, Syrien zur Erlangung des akademischen Grades eines Doktor-Ingenieurs (Dr.-Ing.) genehmigt. Gutachter:

Prof. Dr.-Ing. Raimar J. Scherer, Technische Universität Dresden

Prof. Dr.-Ing. Uwe Rüppel, Technische Universität Darmstadt

Tag der öffentlichen Verteidigung: 29. April 2011

Schriftenreihe des Instituts für Bauinformatik Herausgeber: Univ.-Prof. Dr.-Ing. R. J. Scherer © Institut für Bauinformatik, Fakultät Bauingenieurwesen, TU Dresden, 2011 ISBN: 978-3-86780-228-4 Institut für Bauinformatik, TU Dresden Postanschrift Besucheranschrift Technische Universität Dresden Nürnberger Str. 31a 01062 Dresden 2. OG, Raum Nr. 204 01187 Dresden Tel.: +49 351/463-32966 Fax: +49 351/463-33975 E-Mail: [email protected] www: http://tu-dresden.de/biw/cib

Acknowledgement

From my first day (14.10.2005) as a Ph.D. student at the Institute of Construction Informatics of the TU Dresden until finish writing this thesis (01.08.2010) has been an almost five year journey in academics and research, which simply would not have been successful without the kind help of many people and organizations. I am grateful to my Ph.D. supervisor Prof. Dr.-Ing. Raimar Scherer for his scientific guidance and improvement suggestions.

I appreciate the remarks of Prof. Dr.-Ing. Uwe Rüppel and his taking over the role of the second reviewer of this research work.

I am thankful to every colleague at the Institute of Construction Informatics, but especially to Dr.-Ing. Peter Katranuschkov for his continuous support and for the fruitful discussions with him.

I am also grateful for the kind support of my colleagues Gerald Faschingbauer and Ronny Windisch especially in the last days of finalizing my thesis.

I would like also to thank the Syrian Ministry of High Education for the finical support during my research period in Germany.

Finally, I am grateful for the continuous support and endless love of my family (my mother Rabeha, my brother Yaser, my sister Manal and my future wife Anna), to whom I dedicate this dissertation. I hope as well that my father Mahmoud looks now with satisfied eyes from the heaven at his one year old son whom he left.

Wael Mahmoud Sharmak Dresden, May 2011

Abstract The experience in the construction industry shows that almost no project performs totally as planned. Dynamic changes are frequently needed in different management plans. These changes can be ascribed to the high uncertainty in the planning phase of a construction project, which can be evaluated as potential causes of risks and risks can be in turn evaluated as potential causes of changes in different project management plans (schedule, cost, resources etc.). The knowledge collected from different sources can reduce the uncertainty and, consequently, the error rate in the planning phase. Accordingly, less change will be needed within the execution phase. For this reason, relevant knowledge should be documented in an explicit way to enable all the interested people to share and use their experiences properly. In this work, the schedule as a project management plan is in the main focus. Business Process Modeling techniques are used successfully in different business sectors to document, reuse and enhance the process knowledge in the form of process models. In this work, several concepts from the Business Process Modeling are adopted to build a Process-oriented Knowledge Management System as an adequate and efficient approach for the explicit documentation of the schedule knowledge. Nevertheless, it is mostly impossible to apply the exact process as explicit work schedule in different construction projects. Accordingly, a degree of individuality is required within each use of a construction process. For that reason, a standardized process description is developed that offers a certain degree of flexibility in its content to be usable in different contexts. The developed approach suggests the use of configurable fragments in the course of the process models to express the uncertain parts of the process. Accordingly, an amount of flexibility will be shown when these configurable fragments will be included or excluded from the process model according to the prevailing conditions. The configurable fragments are generalized and described on type level as Configuration Templates. A general structure of a Configurable Reference Process Model (CRPM) is developed as an ontology model, where the Configuration Templates are integrated to express the possible flexibility in the process course of action. The population of the ontology model with the process data builds a Process-oriented Knowledge base, where the CRPMs provide the target process knowledge formation. These CRPMs can be used to plan future akin process schedules. As a result, considerable planning effort will be saved. Moreover, the quality of the process schedules, since they will be derived from the reference process models, will be enhanced. A software architecture for a process-oriented knowledge management system that utilizes the CRPM-Knowledge base as a data source in the background of a management tool realized within this work. This software can be used for a better life-cycle-management (design, retrieval, selection, implementation, and enhancement) of the overall CRPMs. This software architecture consists of three tiers, namely, data, application, and graphical user interface. The data tier contains the CRPM-Knowledge base as a global data source and local databases to store the implemented CRPMs instances. The application tier supports the different stations of the CRPM-life-cycle. The presented approach can be used in the planning phase as well as in the execution phase of the project. In the planning phase it can be used to speed up the planning process and although it ensures getting more reliable process schedules. What-if scenarios can be implemented to study the effect of specific situations without endangering the success of the process objectives. The trigger of each configurable fragment is a risk that can be used, as a part of the checklist for risk management. Accordingly, risks can be identified based on the project relevant CRPMs. In the execution phase this approach can help to accelerate the adaptability of the changed schedules by offering ready integrable solutions for recurring problems. Moreover, it enables the enhancement of the CRPM included knowledge according to the evaluation through implementation. A case study that describes a real construction process is presented later in this work as a proof of the introduced concepts. This case study includes different scenarios that show several stations in the life-cycle of a CRPM of this process. Based on the presented results this research work contributes to the Business Process Management domain as well as to the Project Management domain and more specifically to the scheduling and risk management. It shows even that it is feasible to use concepts from the Business Process Management to develop new needed aspects for the construction project management.

Kurzfassung Die Erfahrungen im Baugewerbe haben gezeigt, dass meistens kein Bauprojekt wie geplant verläuft. Dynamische Änderungen sind in den verschiedenen Plänen des Projektmanagements häufig erforderlich. Diese Änderungen schreibt man der relativ hohen Unsicherheit in der Planungsphase des Bauprojekts zu. Die Unsicherheit kann als potentielle Ursache der Risiken eingeschätzt werden und diese Risiken können wiederum als potentielle Ursache der Änderungen in den Projektmanagementplänen (Ablauf, Kosten, Ressourcen, etc.) angesehen werden. Das aus verschiedenen Quellen gesammelte Wissen kann die Unsicherheit in der Planungsphase und folglich auch die Fehleranfälligkeit verringern. Dadurch werden weniger Änderungen in der Ausführungsphase des Projektes erforderlich. Das relevante Planungswissen soll in einer expliziten Weise dokumentiert werden, um dessen Nutzung und Wiederverwendung durch alle betroffenen Projektbeteiligten zu ermöglichen. In der vorliegenden Arbeit wird nur der Bauablaufplan als ein spezieller Projektmanagementplan betrachtet. Methoden zur Geschäftsprozessmodellierung werden in verschiedenen Industriezweigen erfolgreich angewendet, um das Prozesswissen in Form von Prozessmodellen zu dokumentieren, wiederzuverwenden und zu verbessern. In der vorliegenden Arbeit werden verschiedene Konzepte der Geschäftsprozessmodellierung angewendet, um ein prozess-orientiertes Wissensmanagementsystem als einen sinnvollen Dokumentationsansatz für das Prozessablaufwissen zu erstellen. Allerdings ist es meistens unmöglich, einen spezifischen Prozess als exakten Arbeitsablauf in verschiedenen Projekten zu verwenden. Aus diesem Grunde ist ein gewisser Grad an Individualität bei jeder Verwendung eines Prozesses notwendig. Die standardisierte Prozessbeschreibung soll deshalb die erforderliche Flexibilität in ihrem Inhalt anbieten, damit sie für verschiedene Projektsituationen anwendbar ist. Der Ansatz dieser Arbeit liegt in der Nutzung konfigurierbarer Fragmente im Ablauf von Prozessen, die die Unsicherheit eines Prozesses ausdrücken. Die Flexibilität des Prozessmodells zeigt sich dadurch, dass die konfigurierbaren Fragmente in Abhängigkeit der vorherrschenden Bedingungen in den Prozessablauf einbezogen oder ausgeschlossen werden können. Die konfigurierbaren Fragmente sind generalisiert und auf Typ-Ebene als Konfigurations-muster beschrieben. Eine allgemeine Struktur für das konfigurierbare Referenzprozessmodell (CRPM) wurde als Ontologiemodell vorgeschlagen. Die Konfigurationsmuster sind in diesem Ontologiemodell integriert, um die Flexibilität im Prozessablauf darzustellen. Das mit den Prozessdaten bestückte Ontologiemodell stellt eine prozess-orientierte Wissensbasis dar, in der die CRPMs die anvisierte Prozesswissenstruktur sind. Diese CRPMs können bei der Planung künftiger ähnlicher Prozessabläufe verwendet werden. Hierdurch wird ein erheblicher Planungsaufwand eingespart sowie die Qualität des Prozessablaufs, der aus dem CRPM abgeleitet ist, deutlich verbessert. Es wird eine Softwarearchitektur für ein prozess-orientiertes Wissensmanagementsystem vorgeschlagen, das die CRPM-Wissensbasis als Datenquelle im Hintergrund eines Management-Tools verwendet. Diese Software ist für ein besseres Lebenszyklus-Management (Entwurf, Retrieval, Selektion, Implementierung, und Verbesserung) der CRPMs vorgesehen. Diese Softwarearchitektur besteht aus den drei Schichten Daten-, Anwendungs-, und grafische Benutzeroberflächenschicht. Die Datenschicht besteht aus der Wissensbasis als globale CRPM-Datenquelle und lokalen Datenbanken, die die implementierten CRPMs-Instanzen speichern. Die Anwendungsschicht unterstützt die verschiedenen Stationen im CRPM-Lebenszyklus. Der gesamte Ansatz kann sowohl in der Planungsphase als auch in der Ausführungsphase eines Projektes angewendet werden. In der Planungsphase kann er (1) den Planungsprozess beschleunigen und trotzdem (2) mehr zuverlässige Prozessabläufe liefern. Außerdem kann der Ansatz angewendet werden, um (3) Was-wenn-Szenarien durchzuführen, anhand derer die Auswirkungen spezifischer Situationen und Umstände überprüft werden können, ohne den Erfolg der Prozessziele zu gefährden. (4) Der Auslöser für jedes konfigurierbare Fragment stellt ein Risiko dar, das helfen kann, eine Risikocheckliste zu erstellen. Demzufolge können Projektrisiken auf der Basis projektrelevanter CRPMs identifiziert werden. In der Projektausführungsphase kann dieser Ansatz implementiert werden, um (1) die Anpassung geänderter Ablaufpläne schneller zu realisieren. Dies erfolgt durch die bereit gestellten integrierbaren Lösungen für wiederkehrende Probleme. (2) Durch das Feedback in der Ausführungsphase hilft der Ansatz auch das in den CRPM beinhaltete Wissen zu optimieren. Das stellt sicher, dass die CRPMs aktuell und zuverlässig sind. Im letzten Teil der Arbeit wird im Rahmen einer Fallstudie ein praktischer Bauprozess präsentiert, anhand dessen die Tauglichkeit des vorgeschlagenen Ansatzes überprüft wird. Diese Fallstudie umfasst verschiedene Szenarien, die mehrere Stationen im CRPM-Lebenszyklus darstellen. Basierend auf den vorgelegten Ergebnissen leistet diese Forschungsarbeit einen Beitrag auf den Gebieten des Geschäftsprozess- und Projektmanagements (insbesondere in der Ablaufplanung und dem Risikomanagement). Sie zeigt weiterhin, dass es möglich ist, Konzepte des Geschäftsprozessmanagements anzuwenden, um notwendige neue Aspekte für das Bauprojektmanagement zu erschließen.

Theses

1. In AEC a construction process is a repeated but mostly not identical course of action (semi structured), while a construction project is a unique composition of common construction processes (unstructured).

2. Hardly any construction project goes totally as planned, as relatively high uncertainty exists in the planning phase of a construction project. Consequently, management plans often have to be changed to suit the new project conditions.

3. The uncertainty can be evaluated as potential causes of risks in the project and risks can be in turn evaluated as potential causes of changes.

4. To reduce the uncertainty and, consequently, the error rate in the process planning and execution enough knowledge about the process and its environment should be available.

5. Relevant process knowledge should be documented in an explicit way to enable all the interested people to share and use their experiences properly. Business Process Modeling techniques offer the possibility to document, reuse, and enhance the process knowledge in the form of process models.

6. The uncertainty in the process course of action can be modeled as configurable fragments in the process model. The trigger of the fragment configuration is a risk with a status. The configuration of these fragments will cause changes in the process model by either the inclusion or the exclusion of the configurable fragment.

7. A configurable reference process model provides a compromise solution that solves the conflict between (1) the assumption that construction processes describe always unique objects and, therefore, these processes should be always designed from scratch in each usage and (2) the need to store and document the process knowledge as a standard reusable construction process.

8. Documented process knowledge in the form of configurable reference process models helps to (1) speed up the planning process and (2) to ensure getting more reliable process schedule plans. It helps also (3) to accelerate the adaptability of the changed schedule plans by offering ready integrable solutions for recurring problems. (4) As the triggers of configurable fragments are risks, they can be used as a part of the checklist for risk management. Accordingly, risks can be identified based on the project relevant configurable reference process models.

9. Ontology as a knowledge base is suitable as a repository for the configurable reference process models as it is not possible to assume complete information by the modeling of complex dynamic construction processes. Using an ontology will enable to link the used terms in the configurable reference process models and their semantics.

10. A configurable reference process model cannot cover all the exceptional situations that may affect a process as some interdependencies go beyond the process itself. Therefore, additional Ad-hoc changes may be needed in the planning and execution phases. As an example, spatial dependencies between the deliverables of a construction project may help to identify additional exceptions or conflicts that cannot be described within reference processes.

11. To realize these configurable reference process models in the building practice it is required from the construction companies to structure their knowledge in a process-oriented way. For this purpose, only qualified personnel should carry out the process modeling. Qualification means here that the modelers should possess enough knowledge concerning the construction process technical issues and the modeling issues. Anyway, it must be mentioned that the included knowledge in a configurable reference process model should be dealt with as a guidance to support the planner and not as a restriction to his individual ideas or as a replacement to his experience.

12. The procedures in the background of the configuration templates can be used to carry out the needed schedule changes more quickly than making them manually as usual.

Thesen

1. Ein Prozess im Bauwesen ist ein wiederkehrender, jedoch meist kein identischer Ablauf (teilstrukturiert), während ein Bauprojekt eine einmalige Komposition von üblichen Bauprozessen (unstrukturiert) ist.

2. Bauprojekte verlaufen selten vollständig wie geplant, da eine relativ hohe Unsicherheit in der Planungsphase des Bauprojekts existiert. Infolgedessen müssen Änderungen in verschiedenen Plänen durchgeführt werden, um sie an veränderte Randbedingungen anzupassen.

3. Die Unsicherheit kann als potentielle Ursache der Risiken eingeschätzt werden und die Risiken können wiederum als potentielle Ursache der Änderungen in den Projektplänen angesehen werden.

4. Um die Unsicherheit und folglich die Fehleranfälligkeit bei der Prozessplanung und Ausführung herabzusetzen, sollte genug Wissen über den Prozess und seine Umgebung vorhanden sein.

5. Relevantes Prozesswissen sollte in einer expliziten Weise dokumentiert werden, um dessen Nutzung und Wiederverwendung zu ermöglichen. Geschäftsprozessmodellierungsmethoden ermöglichen das Prozesswissen in Form von Prozessmodellen zu dokumentieren, wiederzuverwenden, und zu verbessern.

6. Die Unsicherheit im Prozessablauf kann in Form konfigurierbarer Fragmente im Prozessmodell abgebildet werden. Der Auslöser für jedes konfigurierbare Fragment ist ein Risiko mit Status. Die Konfiguration dieser Fragmente verursacht Änderungen im Prozessmodell, entweder durch Einbeziehung oder Ausschluss von Fragmenten.

7. Ein konfigurierbares Referenzprozessmodell bietet eine Kompromisslösung an, zwischen (1) der Annahme, dass Bauprozesse immer Unikate sind und (2) der Notwendigkeit Bauprozesswissen in Form von standardisierten wiederverwendbaren Prozessen zu dokumentieren.

8. Das als konfigurierbare Referenzprozessmodelle dokumentierte Prozesswissen hilft, um (1) den Planungsprozess zu beschleunigen und dennoch (2) mehr zuverlässige Prozessabläufe zu liefern. Es hilft weiterhin (3) die Anpassbarkeit geänderter Ablaufplänen schneller zu realisieren. Dies erfolgt durch die angebotenen integrierbaren Lösungen für wiederkehrende Probleme. Der Auslöser für jedes konfigurierbare Fragment in einem konfigurierbaren Referenzprozessmodell ist ein Risiko, (4) das helfen kann, eine Risikocheckliste zu erstellen. Demzufolge können Projektrisiken auf der Grundlage projektrelevanter konfigurierbarer Referenzprozessmodelle identifiziert werden.

9. Eine Ontologie als Wissensbasis ist ein geeigneter Datenbehälter für die konfigurierbaren Referenzprozessmodelle, da es nicht möglich ist, vollständige Informationen über komplexe dynamische Bauprozesse zu besitzen. Die Verwendung einer Ontologie ermöglicht die Verknüpfung zwischen den Begriffen der konfigurierbaren Referenzprozessmodelle und ihrer Semantik.

10. Ein konfigurierbares Referenzprozessmodell kann nicht alle Ausnahmefälle erfassen, die einen Prozess beeinflussen können, da einige Abhängigkeiten den Rahmen der Bauablaufprozesse sprengen. Deshalb können zusätzliche Ad-hoc Änderungen in der Planungs- oder Ausführungsphase notwendig sein. Beispielweise können räumliche Beziehungen zwischen den Produkten eines Bauprojektes helfen, um zusätzliche Ausnahmen oder Konflikte zu identifizieren, die in Referenzprozessmodellen nicht beschrieben werden können.

11. In der Baupraxis ist es noch erforderlich, dass die Bauunternehmen ihr Wissen in einer prozess-orientierten Weise strukturieren, um solche konfigurierbaren Referenzprozessmodelle erstellen zu können. Qualifiziertes Personal, das umfangreiches Bauprozess- und Prozessmodellierungswissen hat, sollte diese Aufgabe übernehmen. Das in den konfigurierbaren Referenzprozessmodellen beinhaltete Wissen sollte als Empfehlung betrachtet werden, die dem Planer zur Verfügung steht um ihn bei seiner Aufgabe zu unterstützen. Es ist auf keinen Fall eine Restriktion seiner persönlichen Ideen oder ein Ersatz für seine Erfahrung.

12. Die Konfigurationsmusterprozeduren können angewendet werden, um die Ablaufänderungen schneller als die üblichen manuellen Anpassungen durchzuführen.

Fakultät Bauingenieurwesen

Dynamic Network Planning in Construction Projects using

Configurable Reference Process Models

Dynamische Netzplanung in Bauprojekten unter Verwendung von

konfigurierbaren Referenzprozessmodellen

An der Fakultät Bauingenieurwesen

der Technischen Universität Dresden

eingereichte

Dissertationsschrift

zur Erlangung des akademischen Grades

Doktor-Ingenieur (Dr.-Ing.)

vorgelegt von

Wael Sharmak

geboren am 20. Juli 1977 in Damassuburb, Syrien

Dresden, 20. Januar 2011

TABLE OF CONTENTS I

TABLE OF CONTENTS

1. Problem Statement, Motivation and Objectives ............................................................................ 1

1.1. Introduction .................................................................................................................................. 1

1.2. Objectives ..................................................................................................................................... 2

1.3. Organization of This Work ........................................................................................................... 3

2. Risk and Change Management for Construction Processes .......................................................... 4

2.1. The Life-Cycle of a Construction Project .................................................................................... 4

2.1.1. The Generic Design and Construction Process Protocol ....................................................... 5

2.1.2. The Fee Structure for Architects and Engineers .................................................................... 6

2.2. The Work Breakdown Structure ................................................................................................... 7

2.2.1. Task-oriented WBS ............................................................................................................... 7

2.2.2. Deliverable-oriented WBS .................................................................................................... 7

2.2.3. Mixed-form WBS .................................................................................................................. 8

2.3. Uncertainty, Risk, and Change Terms .......................................................................................... 8

2.4. The Uncertainty in Construction Projects .................................................................................... 9

2.5. The Risk Management Process .................................................................................................. 11

2.5.1. Risk Management Standards ............................................................................................... 12

2.5.2. A Generalization of Risk Management Standards .............................................................. 13

2.5.3. The Interrelationships between the Steps of the Risk Management Process ....................... 17

2.5.4. Disturbance Risk ................................................................................................................. 17

2.6. Change Management in Construction Projects .......................................................................... 19

2.6.1. Classification of Changes .................................................................................................... 20

2.6.2. Change Orders ..................................................................................................................... 22

2.6.3. Rework ................................................................................................................................ 22

2.6.4. Change Ripple Effect .......................................................................................................... 23

2.6.5. The Change Management Process ....................................................................................... 24

2.7. Existing Work on Risk and Change Management in Construction ............................................ 25

2.8. Discussion .................................................................................................................................. 27

3. Business Process Modeling and Reference Modeling ................................................................... 28

3.1. Basic Issues ................................................................................................................................ 28

3.2. Business Process ......................................................................................................................... 29

3.3. Business Process Management ................................................................................................... 30

3.3.1. Process Modeling Abstraction ............................................................................................. 31

3.3.2. Workflow Management ....................................................................................................... 31

3.3.3. BPM Standards .................................................................................................................... 32

3.4. Process Modeling Patterns ......................................................................................................... 33

II TABLE OF CONTENTS

3.5. Dynamic Aspects in Workflow Systems .................................................................................... 34

3.6. Business Process Modeling Techniques ..................................................................................... 36

3.6.1. Formalization Degree of a Process Modeling Technique ................................................... 37

3.6.2. Existing Business Process Modeling Techniques ............................................................... 37

3.7. Existing Work on the Use of BPM in Construction ................................................................... 45

3.8. Reference Process Modeling ...................................................................................................... 48

3.8.1. Knowledge Management ..................................................................................................... 49

3.8.2. The Life-Cycle of a Reference Process Model .................................................................... 50

3.8.3. Configurable Event-Driven Process Chains ........................................................................ 51

3.8.4. Reference Modeling in the Construction Sector.................................................................. 52

3.9. Discussion .................................................................................................................................. 55

4. Configuration Templates for Dynamic Construction Process Models ....................................... 57

4.1. Starting Basis .............................................................................................................................. 57

4.2. The Ability of BPM to Reflect Scheduling Features .................................................................. 58

4.2.1. Precedence Relationships in a Business Process Model ..................................................... 58

4.2.2. Comparison between Network Scheduling Methods and EPCs .......................................... 60

4.2.3. Deterministic Perspective of a Process Model .................................................................... 61

4.3. Suggested Configuration Templates for Exception Handling in Construction Processes .......... 61

4.3.1. General Templates ............................................................................................................... 62

4.3.2. Interruptive Templates ........................................................................................................ 67

4.3.3. Reactive Templates ............................................................................................................. 71

4.3.4. Formal Representation of the Configuration Templates ..................................................... 73

4.4. Using Configurable Fragments in Process Models .................................................................... 80

4.6. Alternatives Analysis ................................................................................................................. 82

4.5. Discussion .................................................................................................................................. 83

5. A Knowledge-Base for the Specification of Configurable Reference Process Models .............. 85

5.1. Basic Concepts ........................................................................................................................... 85

5.2. Using Ontology Model to Describe the Schema of the CRPM .................................................. 87

5.3. General Requirements on Design CRPM for Construction Processes ....................................... 88

5.4. Structure of the Construction CRPM as an Ontology Model .................................................... 90

5.5. A Conceptual Usage Example .................................................................................................... 96

5.6. The Management Life-Cycle of a Construction CRPM ............................................................. 98

5.7. Discussion ................................................................................................................................ 100

6. Design and Implementation of Software Architecture for CRPM-based Process Management ............................................................................................................................................................. 101

6.1. Basic Concepts ......................................................................................................................... 101

6.2. Design of the Software Architecture ........................................................................................ 103

6.2.1. Process Database ............................................................................................................... 104

TABLE OF CONTENTS III

6.2.2. Structural View of the Software Architecture ................................................................... 105

6.2.3. Behavioral View of the Software Architecture ................................................................. 105

6.3. Implementation of the Designed Software ............................................................................... 109

6.3.1. Process Database ............................................................................................................... 109

6.3.2. The CRPM Knowledge-Base ............................................................................................ 109

6.3.3. Management Tool .............................................................................................................. 111

6.4. Discussion ................................................................................................................................ 113

7. Case Study ...................................................................................................................................... 114

7.1. Scenario 1: Design of a New CRPM ........................................................................................ 114

7.2. Scenario 2: Configuration and Instantiation of a CRPM .......................................................... 118

7.3. Scenario 3: Changes to the Process Model Instance ................................................................ 120

7.4. Scenario 4: CRPM Enhancement ............................................................................................. 122

7.5. Scenario 5: Ripple Effect of Changes ...................................................................................... 123

7.6. Discussion ................................................................................................................................ 126

8. Conclusions and Future Research ............................................................................................... 127

8.1. Conclusions .............................................................................................................................. 127

8.2. Outlook of the Possible Future Research Topics...................................................................... 129

8.2.1. Consideration of the Project Level .................................................................................... 129

8.2.2. Integrate Configurable Resources in CRPM ..................................................................... 129

8.2.3. Multi-Criteria Decision Making ........................................................................................ 130

8.2.4. Ripple Effect of Changes .................................................................................................. 130

8. References ...................................................................................................................................... 131

IV LIST OF ABBREVIATIONS

LIST OF ABBREVIATIONS

AEC Architecture, Engineering and Construction

AHP The Analytic Hierarchy Process

API Application Programming Interface

ARIS Architecture of Integrated Information System

BPEL Business Process Execution Language

BPM Business Process Modeling

BPMN Business Process Management Notation

BPO Business Process Object

CCPM Critical Chain Project Management

C-EPC Configurable Event-driven Process Chain

CPM Critical Path Method

CRPM Configurable Reference Process Model

DB Database

eEPC Extended Event-driven Process Chain

EPC Event-driven Process Chain

EPML Event-driven Markup Language

GDCPP Generic Design and Construction Protocol

GUI Graphical User Interface

HOAI The German fee structure for architects and engineers

ICT Information and Communication Technologies

IDEF0 Integration Definition for Function Modeling

IFC Industry Foundation Classes

IPM Instantiated Process Model

JDBC Java DataBase Connectivity

LIST OF ABBREVIATIONS V

KB Knowledge Base

MCDA Multi Criteria Decision Analysis

OMG Object Management Group

OWL Web Ontology Language

PERT Program Evaluation and Review Technique

PMBOK The Project Management Body of Knowledge guide

PMI Project Management Institute

RBS Risk Breakdown Structure

RC Reinforced Concrete

RDF Resource Description Framework

RW Retaining Wall

SQL Structured Query Language

UML Unified Modeling Language

WBS Work Breakdown Structure

WfMC Workflow Management Coalition

WfMS Workflow Management System

WSDL Web Service Description Language

XML Extensible Mark-up Language

XPDL XML Process Description Language

YAWL Yet Another Workflow Language

1. PROBLEM STATEMENT, MOTIVATION AND OBJECTIVES 1

1. PROBLEM STATEMENT, MOTIVATION AND OBJECTIVES

1.1. INTRODUCTION

The construction industry is a project-based business sector. Each project can be considered a temporary alliance among diverse partners that will execute, in a private or in a cooperative way, several processes. This results in achieving the planned project objectives.

In this industry, the experience showed that mostly no construction project1 goes totally as planned because of the needed dynamic changes to different management plans. These changes can be ascribed to the relatively high uncertainty in the planning phase of a construction project. Several factors play a role to increase the total project uncertainty, such as the lack of experience with a certain type of construction processes, the changeable environment that surrounds and affects a construction process, or the emergence of unpredict-able out-of-control events that may have negative effects on the work plans. In view of that, the risk of changing the already planned course of work as a need to adjust to current situation is really high. Such adjustments could be carried out, in proactive or reactive way, even sev-eral times within the execution phase of the targeted process.

The process knowledge collected from different resources is valuable for the effective process management, as it can reduce the uncertainty and, consequently, the error rate in the process planning will be lower. Accordingly, less adjustment will be needed within the process execution. Hence, this knowledge should be documented in an explicit way to enable all the interested people to share and use their experiences properly. In a view of that, the standardi-zation of construction processes that will include the best process practice can be a possible solution for knowledge documentation. Nevertheless, it is mostly impossible to apply the exact construction process as explicit work route in different projects. This can be ascribed, among other things, to the one of a kind work project environment, e.g. different construction site, owner, partners etc. Accordingly, a degree of individuality is required within each use of a specific construction process. For that reason, a standardized process description should offer a certain degree of flexibility in its content to be usable in different project contexts.

In other business sectors, like insurance, banking and government, different Business Process Modeling techniques were successfully used to standardize and optimize business process knowledge. Moreover, they were used to communicate process contents between different disciplines or else to automate, partially or completely, process execution by developing corresponding management software. Instead of that, for the modeling of construction processes, the traditional network-based methods are still widely used in the practice. These methods have no ICT support in their backgrounds.

Actually, the usage of Business Process Modeling techniques in construction sector is still mostly limited to the academia. This can be ascribed to different reasons. For example, some construction specialists have the opinion that construction processes are unique unstructured

1 The term construction project is used in this work to refer to an enterprise that takes a place in AEC fields. Nevertheless, building project term can be found as a synonym in the AEC literature.

2 1 . PROBLEM STATEMENT, MOTIVATION AND OBJECTIVES

courses of action. Moreover, they believe that the support of industry processes by informa-tion systems is only enabled by strictly structuring the business processes. However, they be-lieve that construction processes have to be designed in each project, from scratch, using tra-ditional network-based scheduling techniques. Accordingly, these processes cannot be stan-dardized using Business Process Modeling techniques. Others do believe that construction processes are manual and cannot even be partially automated and, thus, they are not motivated to engage these techniques in the construction industry.

Nevertheless, it is arguable that construction processes are completely unique, as this indi-cates that the experience gained from past project will never help in future projects, which is not true. On the other hand, it is right that full automation of construction processes is still not possible. However, steps ahead on the way to automate the management of these processes may be achieved using Business Process Modeling techniques. Therefore, it will be interesting to investigate how these techniques may profit, the so described, dynamic unique construction processes by offering new management possibilities that may help to reduce time and costs along with increasing the quality. Based on this, the representation and management potential of the collected construction process knowledge, as dynamic standardized process description, using Business Process Modeling context will be the main focus of this research work.

1.2. OBJECTIVES

The dynamic existing in construction processes demands flexibility in the representation of these processes. This dynamic is attributed to the uncertainty prevails construction project environment. This uncertainty may lead later to change a part of the plans to adapt to the cur-rent situation. Based on this, the development of a method to consider the uncertain events as configurable fragments within the models that describe construction processes is the core part of this effort. This developed method will enable supporting the flexibility in the standard description of construction processes. Accordingly, it should be possible to describe the process-knowledge collected from different projects, including exceptional cases, as reference process models. Subsequently, these reference models can be used to plan future similar processes. As a result, considerable planning effort will be saved. Moreover, the quality of process schedule plans, since they will be derived from the reference process models, will be enhanced.

Therefore, within the scope of this work the following tasks have to be performed:

The analysis of the current state of research concerning (1) construction project management (especially the uncertainty, process risk and change related literature) and (2) Business Process Modeling literature.

The development of a Business Process Modeling based method to describe the uncertain parts of the process as configurable fragments of construction process mod-els and, thus, as parts of the process integrated knowledge.

Using this developed method as a start point to build a schema for a configurable reference process model that is suitable to describe construction processes. This sche-ma should enhance the flexibility and standardization needed in construction processes. Moreover, it should facilitate the design of a knowledge-base for reference

1. PROBLEM STATEMENT, MOTIVATION AND OBJECTIVES 3

construction processes.

The development of a software-prototype for the purpose of the verification of the developed concepts. The developed knowledge-base will play the role of a data source in the background of this software-prototype. Accordingly, this software-prototype is planned to be a management tool to build and optimize configurable reference process models and to use them to plan different schedule scenarios for a specific process case. In view of that, the project team will be supported in anticipating the potential risky events and their impact. Furthermore, the error rate in the process design will be decreased and, thus, the disruptive effects of unplanned situations will be reduced.

1.3. ORGANIZATION OF THIS WORK

The thesis is divided into 8 chapters. Each one starts with an abstract that summarizes the content and gives an indication about the comprised points in the respective chapter. Each chapter ends with a discussion, in which the results concluded from the holding chapter are analyzed and a logical and smooth movement to the following chapter is provided.

Chapter 2 begins with an overview of some features and terms that are used in project management in general and in construction project management in particular. This includes (1) the uncertainty in construction processes, (2) risks in construction processes as uncertain events and their known risk management principles and standards, and (3) changes in con-struction processes as possible results of risk management and, in view of that, some change management aspects in construction industry are introduced.

In chapter 3, a general view about Business Process Modeling (BPM) and reference modeling, their concepts and techniques are demonstrated. After that, existing BPM work in the field of construction processes are studied and evaluated.

The chapter 4 and 5 form the backbone of the work. The results of the literature study, in chapters 2 and 3, are used to develop the configuration templates in chapter 4. The description of these templates is accompanied with a graphical representation and configuration procedures for each of them.

A possible implementation of these configuration templates within configurable reference process models for construction processes are presented in chapter 5. This includes the struc-ture of a knowledge-base that will hold these reference process models, built as an ontology model, and a conceptual example that will illustrate how to configure a reference model selected from this knowledge-base according to some case conditions.

In chapter 6, the usage of this knowledge-base as a data source for a process management software tool is presented. Moreover, this chapter includes the design of the architecture of this software tool, as well as, the implementation of the suggested software design.

The validity and usefulness of the developed concepts are proved in chapter 7 using real con-struction processes as case studies.

Chapter 8 concludes the whole research work. The suggested concepts are summarized, evaluated and viewed critically. Accordingly, the contributions to the project planning, project management and Business Process Modeling for construction processes are listed. Moreover, an outlook toward the possible future research topics, based on this work, is presented.

4 2. RISK & CHANGE MANAGEMENT FOR CONSTRUCTION PROCESSES

2. RISK AND CHANGE MANAGEMENT FOR CONSTRUC-TION PROCESSES

Construction is a project-based industry. Each construction project is to some ex-tent unique as it has a special construction product, different working team, diverse stakeholders, different start date and duration. The construction processes are characterized by carrying a bigger amount of uncertainty than what is in other business processes. Consequently, these processes show obvious dynamic aspects, which are realized by the frequent risks and changes accompanied with all development phases that a construction product will pass through. In this chapter, some general aspects, related to construction projects and their man-agement, are introduced, which help later to build the targeted approach of this work. After that a detailed analysis of the terms, uncertainty, risk and change in the construction project management are outlined to highlight the characteristics, the inter-relationships, and the effect of these terms on the construction processes.

2.1. THE LIFE-CYCLE OF A CONSTRUCTION PROJECT

A construction project is an enterprise, which takes a place in the fields of architecture and civil engineering; it involves the building or assembling of one or more structures and infrastructures products. Such an enterprise is usually realized by a temporary alliance of independent autonomous partners. Each partner uses different techniques to execute his part of work, as well as, has special project perspectives. The whole project can be divided into several phases to assure better management and control. One of the objectives of this break-down is to formulate the project schedule. In this schedule each work package generates a product. Each one of these products results from the processing of the resources and informa-tion by one or more of the project participants. The processing of each work package must be adjusted to the boundary conditions of the whole project and in respect to, amongst others, the project organization, project structure and infrastructure. This can be considered true for the planning as well as for the execution phases. In the project planning phase target values of each work package will be assigned for the performance, schedule, and cost. Accordingly, the project progress can be monitored and controlled by means of target-actual comparison and correspondingly corrective measures can be initiated. Thereby, the project plans can be adjusted through the course of the project according to the current prevailing conditions in a trail to keep or to enhance the targeted objective.

The life-cycle of a construction project is a part of the construction product life-cycle (see figure 1). It defines the phases that connect the project beginning to its end. The transition from one phase to another in the life-cycle involves some form of technical transform. Deliverables2 from one phase are usually reviewed for completeness and accuracy and approved before work starts in the next phase. It is also possible that a phase will begin before the approval of the deliverables of the previous phase; e.g. by using the fast tracking method.

Some organizations tried to standardize all the construction projects with a single life-cycle while others allow choosing the most appropriate life-cycle for the project. Both types of 2 A deliverable is a measurable and verifiable work product; it can be tangible or intangible one.

2. RISK & CHANGE MANAGEMENT FOR CONSTRUCTION PROCESSES 5

approaches share the following characteristics according to the PMI (2004):

The phases are sequential and are defined by some form of information or component hand-off.

At the start of the project, the level of uncertainty is the highest and, therefore, the risk of failing to achieve the project’s objectives is bigger.

As the project continues, the certainty of completion gets progressively bigger.

The ability of the stakeholder to influence the final characteristics of the project’s products is the highest and the less costly at the project start and gets progressively lower as the project continues.

The whole construction project life-cycle contains the following essential phases: (1) defini-tion, (2) planning, (3) execution and (4) delivery. Other additional phases may be also needed such as, the operation, the re-planning, and deconstruction. This is decided according to many factors, like the contract type and the project current conditions.

Figure 1: The relationships between the project and the product life-cycles in a building

Some approaches for the standardization of the building life-cycle will be described in some detail in the following section.

2.1.1. THE GENERIC DESIGN AND CONSTRUCTION PROCESS PROTOCOL

The Generic Design and Construction Process Protocol (GDCPP 2001) was developed in

1998 at the Salford University with the aim of providing a framework to help companies to

achieve an improved design of construction projects. The result was a reference process

model, which can be used by the planner or the construction companies for the reengineering

and optimization purposes of their private business processes.

The GDCPP model is subdivided into four board stages representing the whole life-cycle of a

construction project (see table 1). Each stage is in turn subdivided into several phases (see

figure 2). Within each stage there are different processes that should be carried out. A process

is a set of tasks undertaken to produce information as process deliverables. Moreover, there

are nine Task Zones in the process protocol map representing different groups of participants

involved in a construction project. Each process may span over one or more

Task Zones. The generic protocol is brought down to a secondary-level, product-specific lev-


el, which can itself be broken down further to more detailed levels.

Figure 2: Cut-out of the GDCPP model showing the phases of the pre-project stage (GDCPP 2001).

An ICT tool “The Process Protocol Map Creation Tool”, supporting the methodology behind the GDCPP, was developed to enable the production of the project process map based on the generic process protocol framework. This tool assists in customizing project process maps and managing their processes.

Stage Phase Name

Pre-project

0 Demonstrating the need 1 Conception of need 2 Outline feasibility 3 Substantive feasibility study and outline financial authority

Pre-construction 4 Outline conceptual design 5 Full conceptual design 6 Coordinated design, procurement and full financial authority

Construction 7 Production information 8 Construction

Post-construction 9 Operation and maintenance

10 Disposal

Table 1: The project board stages and their phase in the GDCPP methodology

2.1.2. THE FEE STRUCTURE FOR ARCHITECTS AND ENGINEERS

The fee structure for architects and engineers (German: Honorarordnung für Architekten und Ingenieure (HOAI))3 is a German regulation controlling the payments of the services done by architects and engineers. Additionally, HOAI contains a phase-oriented structured service catalogue of a construction project. Usually, the project planner prepares such a service cata-logue to accomplish the project in collaborative work with other involved parties. A typical planning progress is classified in HOAI in nine service phases. Each of these phases is in turn subdivided into basic and special services. These service phases are:

3 http://www.hoai.de/


1. Basic evaluation 2. Preliminary planning (project and planning preparation) 3. Basic design (system and integration design) 4. Approval planning 5. Execution planning 6. Award of contract preparation 7. Participation in the award of the contract 8. Site supervision 9. Building maintenance and documentation.

2.2. THE WORK BREAKDOWN STRUCTURE

In project management, work breakdown structure (WBS) is a method used to define a multi-level hierarchy of a project’s discrete deliverables or tasks in a graphical representation or textual outline of the project scope. It helps the project participants to develop a clear vision of the end product produced by the project. It supports also the decomposition of project scope into simpler components and, consequently, simplifies the management of complex projects. WBS provides the basis for integrating and assessing schedule and cost performance. It supports the assignment of responsibilities, the identification of resources and setting the work sequence. The WBS code uses a numbering scheme consisting of numbers separated by periods. This allows for easy and systematic expansion of the WBS as additional elements are added. However, it may not be needed or not be possible to decompose all the branches of the WBS to the same level of detail.

One of the main principles of the WBS is the 100% rule. It is applied to all levels within the hierarchy and states that: “the sum of the work at the child level must equal 100% of the work represented by the parent level” (PMI 2006).

A WBS can be built according to the task or the product perspectives in the project or using a mixture of them.

2.2.1. TASK-ORIENTED WBS

According to this perspective the whole project will be subdivided into different work sections (figure 3 left). Templates can be offered by Standard Service Catalogs (SSCs) to establish task-based WBSs. Such catalogs describe standardized tasks and provide the opportunity to store non-redundant master records. The Standard Service Book (STLB-BAU)4 offered by the German DIN standard is an example of such catalogs. STLB-BAU represents a classification system used for the description of the building services.

2.2.2. DELIVERABLE-ORIENTED WBS

Here, the whole project will be divided, in a hierarchical way, into its building elements until no more useful breakdown can be done (figure 3 right). A possible product-based WBS for building construction can be made using the German DIN 276 “Cost estimation in construction”.

4 STLB-Bau_dynamische Baudaten: http://www.stlb-bau-online.de/


Also, a product model such as STEP AP 2255 or the Industry Foundation Classes (IFC)6 offers the possibility to breakdown a building according to its product perspective.

2.2.3. MIXED-FORM WBS

In the mixed-form of WBS the project will be broken down according to its deliverables. Some certain elements, usually the leaf deliverables in the hierarchy, will be broken down according to the tasks needed to produce these elements.

Figure 3: Examples of task-oriented (right) and deliverable-oriented (left) WBS

2.3. UNCERTAINTY, RISK, AND CHANGE TERMS

In general, a construction project consists of multiple interdependent aspects and involves multiple feedback processes. Its interdependent aspects demonstrate various nonlinear relationships, as their causes and effects do not have simple proportional correlations. This all makes “the complexity” accompanying with any definition and description of construction projects. Moreover, the uncertainty faced in construction is bigger than what can be faced in other industries, which will add the dynamic to its complex nature.

Generally, the uncertainty in construction is a result of the lack of needed reliable information, which can be attributed to different environmental, organizational, or technical factors. The role and importance of each factor differs from project to project according to the specific project characteristics and to its surrounding environment. This uncertain nature may lead to a big variance between the results of deterministic methods used for project management planning and real practice. For instance, the reliability of deterministic task duration and cost estimate methods in a project that may be over a span of many years is really questionable. Usually, the deviation of the project management baselines can be reduced when the degree of uncertainty in the project can be decreased. This can be done as

5 STEP AP 225: The Standard for the Exchange of Product model data. It is a comprehensive ISO standard that describes how to represent and exchange digital product information. 6 IFC is an open standard format used for the digital description of building information models. This format can be used to exchange and share Building Information Modeling data between different applications.


soon as a comprehensive knowledge about the project is available. As the practice in construction is project-based, better knowledge can be acquired from lessons learned and experiences gained from the past projects. This knowledge will help to make better planning decisions as well as to reduce mistakes on past projects to be repeated. When the project progresses, the accuracy of the made decisions becomes more clear and the ambiguity disappears gradually. However, it is generally impossible to acquire a comprehensive knowledge about the project in advance. Therefore, a systematic risk analysis should be undertaken to evaluate the project’s risks and opportunities and, consequently, to reduce the negative effect of uncertainty on the project objectives. In such an analysis the risks in the project will be identified, the rating of each risk will be estimated according to the available information, and a suitable way of treatment or contingency plans will be adopted. This will result in implementing some changes in the project plans in the planning phase of the project. Nevertheless, changes in construction projects are likely to occur at any stage and can affect different project management plans. In the literature on change management (Lee et al. 2006; Sun et al. 2006; Hao et al. 2008) it is emphasized that changes are inevitable in construction projects even if comprehensive studies have been made. Consequently, mostly no construc-tion project goes totally as planned, as for example, the risks of cost and schedule overruns, as well as resources unavailability are common to face. Some change causes are even impossible to be identified in advance, e.g. human errors. Other changes may not have known parameters for analysis, such as changes caused by new preferences of the client. The uncertainty in the project should be evaluated as potential causes of risks in the project (PMI 2004). Risks should in turn be evaluated as potential causes of changes in the project management plan (figure 4). Based on this, a risk represents an uncertain event, which will invoke one or more changes in the project plan. Therefore, in the following, an overview about uncertainty in general and, more specifically, in the construction sector is given. After that, the risk man-agement process, and some related standards and techniques are mentioned. Then, the change management process and the developed risk and change specifications as well as approaches in construction literature will be discussed in some detail.

Figure 4: The possible causality between uncertainty, risk and later change.

2.4. THE UNCERTAINTY IN CONSTRUCTION PROJECTS

The uncertainty can be defined as a work state or a result that its extent, value, or outcome is


not expected. It concerns the lack of knowledge about the problem at the point of time a decision has been made. Consequently, projects using first-of-its-kind technology or highly complex methods tend to have more uncertainty, see PMI (2004).

According to Sharmak and Scherer (2009), the degree of uncertainty faced in construction projects is mostly higher than in other manufacturing sectors because of, amongst others, the following reasons:

In construction projects many assumptions have to be made based on incomplete information. Such assumptions may be insufficient and, consequently, can endanger the progress of the project. This is mostly the case in fast-track projects, which is common to use in construction to speed up the project and as a result to reduce the time to market. In such a project, planning and execution phases progress in parallel and, consequently, the execution is based on unfinished and maybe to some extent unreliable plans.

The boundary conditions, under which a construction project is assumed to be done, are changeable. For example, if the project will be executed over a span of many years the legislative, environmental, or economic conditions will probably change.

Different alternative execution methods can be used to build the same product in construction (cf. König & Tauscher 2006). The choice between the variants is a matter of decision making. Taking the proper decision is not always certain as it is related to the experience, the methods, and the current information the decision maker has.

Manual tasks have a large portion in most construction processes. The execution of these tasks is strongly related to the human performance. This is in turn affected by different factors, such as age, state of mind, physical health, attitude, emotions etc. Consequently, the error-rate within the construction processes is relatively high.

Uncertainty can be classified into different types according to the categories that it may affect in the project. Based on literature review on uncertainty and risk management (De Meyer et al. 2002; BMI 2004; Loosemore et al. 2006) the following types of uncertainties can be concluded:

Schedule uncertainty; indicates the uncertain ability of the project to be executed within the planned time and using only the planned tasks.

Cost uncertainty; indicates the uncertain ability of the project to be executed within the planned budget.

Environment uncertainty; refers to the uncertain nature of the political, economic societal, or legislative project environments.

Performance uncertainty; refers to the uncertain ability of designed tasks to meet desired quality criteria. It can also indicate uncertainty in the maturity of the used technology, technology obsolescence, or technology effectiveness.

Client uncertainty; refers to the uncertain project scope defined by the project client. It appears because clients are rarely able to articulate all their needs specifically, because they either face uncertainty themselves or cannot define needs on products that do not yet exist.

Different uncertainty categories influence each other and, consequently, increase the total uncertainty faced by a specific project. In this work, the main focus is on the schedule uncertainty as well as the effects of other uncertainty categories on this category.


By considering uncertainties as unknowns, de Meyer et al. (2002) have classified them into two main categories: Known Unknowns and Unknown Unknowns (see figure 5). These categories are defined on the basis of their relation to project management techniques. By reflecting this classification to construction industry it can be said that Unknown Unknowns refer to the absence of knowledge in the planning phase. Such uncertainties represent events that are unforeseen as no related causes could be identified using risk identification techniques. These events may appear suddenly in the project and leave negative effect on the progress as (a) there are no contingencies prepared against, and (b) usually they occur in the post-fixity stage of the project, which makes them more detrimental. Examples of such uncertainties are: owner scope and preference change, execution errors, etc. On the other hand, Known Unknowns are those uncertain events which can be identified as their causes are known, or can be measured and evaluated. Therefore, contingencies or treatment strategies can be adopted proactively to deal with them in case they were proven as real project risks, such like ground water risk on underground building parts.

Figure 5: Types of unknowns in a project (based on De Meyer et al. 2002)

2.5. THE RISK MANAGEMENT PROCESS

According to PMI (2004), risk management is “the systematic process of identifying, analyzing, and responding to risks; this process includes maximizing the probability and consequences of positive events and minimizing the probability and consequences of adverse events to project objectives”, e.g., cost, schedule, performance, safety and environmental sustainability. Accordingly, a risk event can be defined as an uncertain event that may have positive or negative consequences on one or more project objectives. Accordingly, the consequence of a risk can be a gain or a loss as a risk can be an opportunity or a threat.

Each risk has in general some trigger factors that are associated with it. Their values can increase or decrease the probability of the risk occurrence. There may be a range of possible consequences associated with one risk. On the contrary, one consequence may be the result of more than one risk (see figure 6). The probability of risk occurrence and the intensity of its consequences can be expressed qualitatively or quantitatively. The decision to treat a specific risk is made according to the so called Risk Threshold. It is a parameter associated with the risk indicating if a risk treatment should be triggered or not. The value of the threshold refers to cost, time, or quality, and it is agreed upon by all project parties involved. The treatment of risks can be in general a form of provisions to the duration, cost, or resources of the project management plan. Such provisions, called Contingency Reserves are used as allowances for anticipated but not certain risks. Thus, this type of all-purpose proactive treatment is not a response to a specific risk and, therefore, it does not consider exactly where and why to change the respective plans.


Figure 6: Interdependency among trigger factors, risks, and consequences, after Sun et al. (2006).

2.5.1. RISK MANAGEMENT STANDARDS

Several available risk management standards and guidelines describe systematically the general management steps to be done to deal with the risks such as The Australian and New Zealand Standard (AS/NZS 4360 1999) and Risk Management - Principles and Guidelines (ISO 31000, 2009)7. These standards present high level steps and techniques that may be applicable to a wide range of industries. The risk management experts in each industry field may adopt some suitable methods from the standards for their specific cases. In the following an overview of several known risk management standards is presented.

2.5.1.1. THE AUSTRALIAN AND NEW ZEALAND STANDARD

The Australian and New Zealand Standards of risk management are widely acknowledged for risk management. These standards identify the management steps to be done in:

Establishing the context,

Identify risks,

Analyze risks,

Evaluate risks,

Treat risks,

Communicate and consult,

Monitor and review.

Figure 7: Risk Management interaction and overlapping diagram, after AS/NZS 4360 (1999)

7 http://www.iso.org/iso/catalogue_detail?csnumber=43170


2.5.1.2. THE PROJECT MANAGEMENT INSTITUTE STANDARD

The Project Management Body of Knowledge Guide (PMBOK) is an attempt to document and standardize generally accepted project management information and practices (PMI 2004). PMBOK can be considered as a collection of processes and knowledge areas, which are widely accepted as best practice within the project management discipline. Within PMBOK nine knowledge areas8 were defined, which can be considered typical of almost all projects.

Project risk management is one of these described knowledge areas. This suggests several management steps to implement risk management process in projects. The interrelationships between the steps are described as Inputs and Outputs, as well as, different tools and tech-niques to carry out each step are described. The mentioned steps within the risk management process in PMBOK are:

Risk Management Planning; Risk Identification; Qualitative Risk Analysis; Quantitative Risk Analysis; Risk Response Planning; Risk Monitoring and Control.

2.5.1.3. THE BRITISH STANDARD

A British risk management standard was published in 2002 by the Association of Insurance and Risk Managers (AIRMIC), the National Forum for Risk Management in the Public Sector (ALARM) and the Institute of Risk Management (IRM). This standard is based on the terminology for risk set up by the International Organization for Standardization (ISO) in its recent document ISO/IEC Guide 73 Risk Management-Vocabulary-Guidelines for use in standards (2002). In this standard, the main risk management steps are listed as follow:

Risk Assessment; Risk Analysis; Risk Evaluation; Risk Reporting and Communication; Risk Treatment; Monitoring and Review of the Risk Management Process.

2.5.2. A GENERALIZATION OF RISK MANAGEMENT STANDARDS

Although there are some differences among risk standards in the naming and the sequence of risk management steps, there are still general similarities available. Accordingly, it can be said that generally the risk management process should contain but not be limited to the following steps:

Risk Identification

Risk identification means to determine which risks may affect the project and to document

8 These knowledge areas are: Project (Integration, Scope, Time, Cost, Quality, Human Resources, Communica-tions, Risk, and Procurement) Management.


their characteristics. Risk identification is an iterative process which may be repeated for several times within the project lifecycle. Different techniques can be used for risk identification purpose, for example:

Brainstorming; that is performed by the project team and multidisciplinary external experts to identify potential project risks.

Checklist analysis; which is based on historical information that have been gathered from pervious similar projects. In fact, Risk Breakdown Structure (RBS) can be used as checklist for risk identification as well.

Cause and effect diagram; which is one of the diagramming techniques that can be used to identify risks according to their causes. Moreover, potential risk consequences can be identified.

Questionnaires; project team and risk experts may participate in such risk questionnaires. The results are summarized and studied to conclude an agreed risk list. This technique may need to be repeated several times to reach a consensus about po-tential project risks.

Risk Assessment

This step aims to calculate the impact and likelihood of identified risks and to prioritize the risks according to their potential effect on the project objectives. The overall risk ranking result can be used to determine to response to the risk or not. Risk assessment can be divided mainly into qualitative and quantitative processes. In the following, some techniques that can be used for risk assessment are in brief described:

Probability and impact matrix; is used to prioritize risks qualitatively based on their probability and impact ratings. These risks can then be organized in a table-like matrix according to their ratings (figure 8). Therefore, risks that have low, moderate, or high probability/impact can be easily determined (Wideman 1992).

Figure 8: Probability and Impact Matrix, adapted from PMI (2004).

Probability distributions; can be used to represent quantitatively the uncertainty in project related values, such as task duration or component cost. Uniform, Beta, and Triangular distributions are widely used in project management. Triangular distribution is used for example to represent the uncertainty in task duration in PERT scheduling method (Uher 2003). This is represented as three duration values, namely Optimistic (OD), Most-likely (MD), and Pessimistic Duration (PD) (see figure 9).


Figure 9: Uncertainty in task duration represented using triangular distribution

Modeling and simulation; simulation of risks is typically performed using Monte Carlo technique to translate the uncertainties into their potential impact on project objectives (Kendrick 2003). Other modeling and simulation methods can be used to evaluate the reliability of different management aspects. For example, Precedence Diagramming Method (Uher 2003) can be applied for schedule risk evaluation.

Risk Treatment Planning

Risk treatment planning is the step of determining actions to enhance opportunities and reduce threats to the project’s objectives. This step must be appropriate to the severity of the risk, timely successful, agreed upon by all parties involved.

Several general strategies can be used for risk treatment planning. Treating one risk may need one or more of these strategies. The most widely used strategies for risk treatment are listed in the following.

Risk Avoidance; which can be done by changing the project plan or even the scope to eliminate the possibility of threat occurrence in the project life cycle (Frigenti & Comninos 2002). This means, not to proceed with at least one task that is likely to generate risk. The avoidance maybe done on trade-off basis, in which a more expensive but less risky method will be chosen instead of a less expensive but more risky one.

Risk Acceptance; this strategy can be divided into active acceptance, i.e. to accept the risk and consider treatment options, and passive acceptance, which means to accept the risk as it is, so no further treatment is appropriate or possible at that time. Usually this strategy is used for residual risks, minor threats.

Risk Mitigation; seeks to reduce the probability of occurrence or consequences of a threat or both of them to an acceptable threshold, e.g., schedule risk consequences can be mitigated by adding resources or time to the schedule or even by changing some parts of the planned schedule.

Risk Transference; this strategy is seeking to shift, in whole or in part, the consequence of the threat to a third party together with the ownership of the response. This may include the use of insurance arrangements, partnership, contracts,


performance bonds, warranties and guarantees. This method is most used and effective in dealing with financial risks.

Risk Sharing; means to share the risk with other parties to give the project the best chances to get rid of the threat and seize the opportunity. A typical example for that is in the formation of a joint venture.

Risk Monitoring

It is an ongoing process for the whole project life-cycle. It means to keep track of the identified risks, monitoring residual risks and to register new risks. According to this process, the need of another risk management cycle will be determined e.g. in case that new risks are detected. Several techniques can be used to observe the project progress from different perspectives such as:

Variance analysis; which is used to compare the actual situation with the planned one, i.e. actual-target analysis. This analysis will need the use of project performance data as input and the outcome may anticipate potential schedule and cost deviations.

Reserve analysis; aims to compare the remained cost and time contingency reserves with the remained risk at any time in the project, in order to determine if the remaining reserve is enough to absorb the risks remained.

Risk Treatment

This step includes a concrete action, which will execute the planned strategies and may change the project management plan to respond to the risk event. Risk treatment must be agreed upon by all the involved parties in the project, as well as, it should be appropriate to the severity of the risk.

The method of risk treatment is deeply affected by the timing of its implementation within the project. Therefore, risk treatment is assumed to be consistent of two parts, namely, proactive and reactive treatment. Proactive treatment is the traditional type within risk management, in which anticipated high probability/impact risks are treated by executing the planned treatment strategies. This is typically done before execution stage starts or at least before the risk evolves to a real problem and affects the targeted tasks. However, reactive treatment seems to be inevitable as it is impossible to identify and treat all potential risks in advance.

Risk Documentation

Risk documentation is a part of the total project documentation. It should be done periodically within the project life-cycle and also at the end of each stage in the project. The last documentation should be done within the contract closeout. The results of the applied risk management should be analyzed and related information should be maintained for future use in similar situations. Electronic data processing techniques can be used for documentation purposes such as risk databases, project management software. Such tools enable flexible and easy access to the risk-related information as well as result optimization. Risk-related documentation may include the causes of risks, corrective actions, reasoning behind the corrective action chosen, and other types of lessons learned from risk management reporting. Lessons learned from risk management are documented so that they become a part of the historical database for both the project and the performing organization (PMI 2004).


2.5.3. THE INTERRELATIONSHIPS BETWEEN THE STEPS OF THE RISK MANAGEMENT PROCESS

Some risk management standards introduced the interrelationship concept between risk management steps in the shape of a diagram (figure 7). Such diagrams are based on the behavior of each step within the whole risk management process.

The steps of risk management (mentioned in 2.5.2) show different behaviors within the life-cycle of the whole project. For example, the risk monitoring process is an ongoing process for the whole construction phase; the documentation process must be implemented periodically and at each stage closeout. Risk identification and risk assessment may be repeated several times within the project life-cycle depending on many factors. Accordingly, Sharmak et al. (2007) classified these steps of risk management into four groups according to their manner of appearance within the project life cycle:

Repeated steps; are risk identification, assessment, and treatment planning. These steps may need to be repeated several times within the whole process life cycle. This iteration depends on many factors e.g. new stage started, new available information, the demand of more reliable results, or new risks surfaced.

Periodic processes; such as the documentation process which should be done periodically e.g. monthly documentation.

Continuing steps; such as the monitoring. This step is an ongoing one for the whole lifecycle of the project construction phase to monitor residual risks, keeping track of the identified risks, and identifying new risks.

Exceptional steps; such as the risk treatment, it is considered exceptional because it will be adopted only conditionally. This means that it will be implemented only when the risk threshold (qualitative or quantitative) has exceeded the agreed value. Although, the practice of risk management in construction shows that even for such risks, treatment is not implemented always in proactive way. Actually, there is a tendency in the construction industry to leave problems and react to them when they have occurred, rather than dealing with them in advance (Loosemore et al. 2006).

In accordance with this categorization, on figure 10 a revised diagram of the interrelationships between the risk management steps is presented. It is divided into two cycles based on treatment timing, i.e. (1) proactive and (2) reactive.

Figure 10: Proactive and reactive risk treatment cycles, after Sharmak et al. (2007).

2.5.4. DISTURBANCE RISK

Disturbance is a special type of risks that is faced commonly in construction project. It refers usually to the construction progress disturbance (German: Bauablaufstörung). It can be defined as uncertain event that will cause an interruption or a delay in the work progress. Consequently, they cause a significant discrepancy between the target and actual schedule (cf.


REFA 1991 & Gehbauer et al. 2007). Of course, not all disturbances in the construction site can be considered, but only those, which have a significant influence on the construction management plan. For example, the impact of a major defect in the main tower crane in a project is much bigger than the impact of several minutes delay in delivering ready-mixed concrete. Disturbances are common to find in the daily work level of the construction site, but daily project plans are very rare to use in construction (Gehbauer et al. 2007). Therefore, the reaction to the daily disturbances are not planned but usually carried out in an ad hoc way by the site engineer or site foreman according to their experiences.

Disturbances can be subdivided into external and internal. External disturbances can be ascribed to natural, legislative, or economical events. Internal disturbances may be ascribed to the construction site work or to the procurement of the needed materials. Nature related risks can be considered as disturbances to the project progress totally or partially. As most construction projects have open-air work, natural factors may bring consequential incidents, such as landslides, flooding and failure of temporary earth-retaining shields. If the resulting risk is serious, the construction work may stop for some time, or may not proceed safely or effectively. Therefore, certain changes to the original project plan will have to be made before the work can be resumed.

Gehbauer et al. (2007) concluded a statistical-based classification of disturbances derived from fulltime observation of several construction sites. Accordingly, a number of 95 construction operation disturbances were registered and sorted according to their causes into nine types as shown in pie chart in figure 11. As pointed, execution errors have the largest share with 42% of the recorded disturbances, followed by information problems with 27%.

Figure 11: Disturbances registered at construction sites, sorted according to cause, after Gehbauer et al. (2007)

Some disturbances, like seepage in the excavation walls because of the ground water or wind disturbance in a high-rise construction project, can be considered as known unknowns. There-fore, proactive measures can be planned to avoid their negative consequences. Otherwise, reactive treatment will be needed to deal with the already occurred disturbance. The reactive treatment of disturbances aims to continue the disturbed part of the project. It may include


inserting new tasks or changing some of the planned project tasks to be able to progress again in the planned work.

2.6. CHANGE MANAGEMENT IN CONSTRUCTION PROJECTS

Change management is the process of evaluating the ability to facilitate the proposed change, approving it by the involved project parties, then implementing it within the modified or original project context, and analyzing its effects on the project management baselines.

If the design development of a particular element in the project has been signed off as complete and ready for execution, then making changes to the design are not preferred. Otherwise, making changes is easier from the contractual and technical point of view. The point in the project when the design development is complete is called the fixity point (CIRIA 2001). Accordingly, changes can be pre-fixity or post-fixity actions. The effect of changes in the post-fixity stage on the project is severe as the management baselines have been adopted and they have been partially implemented.

Generally, the probability of introducing changes is higher in the early phases of the project than in the late phases. In contrast, the detrimental consequences of changes are higher if a change is introduced in the late phases of the project (see figure 12).

Figure 12: Timing effect on change opportunity/impact, after CIRIA (2001).

To enable making changes in a project, change clauses must be a part of any legal construction contract. They provide a mechanism for contract modification and for appropriate compensation. From the owner’s perspective such clauses gives the right to make changes within certain limits and through a well-defined way. These changes should be within the general scope of the contract. From the contractor’s perspective, change clauses insure the monetary recovery. In this way, minor dynamic change conditions can be dealt with rapidly and without invalidating the contract or a need for change orders. Major changes needed in the project may require modifications in the project contract. Therefore, changes should be legally and technically approved by the owner and the contractor in the form of the so called Change Order. The documented approval of a change refers in general to the feasibility and the importance of this change to the intended partners. Change disagreement by one of the


issue partners refers to the infeasibility, unimportance, or the disadvantage of this change from the partner economic or technical perspectives. Such disagreement may lead to contract disputes and, therefore, affect the progress of the whole project and lead to project failure (Elwert &Flassak 2008).

2.6.1. CLASSIFICATION OF CHANGES

Changes can be classified in various ways according to different perspectives. For example, from the project management plan9 viewpoint changes may affect different subsidiary plans. Accordingly, the following classification of changes can be formed:

Changes in the project schedule plan; such changes may appear by adding new tasks, cancelling planned tasks, substituting some tasks needed for one of the project products. Changes can be also done by increasing or reducing the time needed for one or more of the planned tasks. This may affect the general project duration or change even the critical project path.

Changes in the project cost plan; as a consequence of increasing or decreasing the cost of the elements needed for some products, or because of changes in the product itself, which will lead to changes in the cost as well.

Changes in the procurement plan; as a result of market condition, the assigned suppliers may have to be changed, or the contracts with them may need to be revised.

As it is known, no one of the project subsidiary plans is a stand-alone one. All these plans are dependent on each other as they are representing the same project but from different perspectives. Therefore, change in one of these plans may cause change in other plans as well. For example, if a change in the schedule will be done by adding a new task, then this will increase the estimated cost given in the cost plan and it may change as well the resource allocations and procurement plan.

Moreover, as a project consists of several processes and each process has several tasks, the changes can be classified from the process-hierarchy perspective to three types, i.e. the project, the process, and task changes. In a construction project it is actually not possible to work on one of these levels without considering the changes on the other two levels, as the changes in a level can propagate changes on the other interrelated levels10. Accordingly, changes on the project and the task levels can be mapped to changes on the process level and vice versa. A more detailed description of these three levels of changes is in the following:

Project changes; are the changes that can affect the duration of the project, the project budget, or even the expected product of the project. As an example, if the duration of the project will be shortened, changes in the relationships between its processes, e.g. parallel instead of sequence, may be undertaken if applicable. Otherwise, the duration of one or more of the processes correspondingly needs to be shortened which means that some adjustments to the task relationships within the process or even to the task

9 According to (PMI 2004) the project management plan can be composed of subsidiary plans which include, but are not limited to: scope, schedule, cost, quality, communication, procurement, and risk management plans. 10 Other intermediate levels in the process-hierarchy are not considered in this classification.


durations within the process will be needed.

Process changes; can be caused by the modifications to the expected deliverable produced by the process, or by problems that are encountered through the process execution. These changes may lead as well to change the task relationships, or a planned task in the process may be canceled or substituted or even a new task may be inserted.

Task changes; concern mostly the attributes of the task and more specifically the duration and cost of the task. Duration changes include start or end time of the task or even both of them. A change in the task duration can affect the corresponding process duration if the task is on the critical path of the process or if the float reserve is not sufficient on the path on which the task is located.

It can be said from another perspective that there are required changes as well as optional changes. Required changes must be accepted by the client or his representative as there are no alternatives available. Such changes are beyond the control of both the client and the contractor. Optional changes can be implemented or not according to different factors. Cost-benefit analysis results can play a main role in making the decision to adopt the optional change.

From the consequences perspective, changes can be beneficial if a change will improve the design, or if it can bring more profit to the contractor and in the same time suits more the client scope. In contrary, a change can have negative consequences on a least one party of the project. These consequences can be cost and time overrun, low productivity, loss, or even dispute.

According to the timing perspective, it can be differentiated between pre-fixity and post-fixity changes in addition to proactive and reactive changes.

Based on this, Motawa et al. (2007) classified changes to different groups according to time, need, and effect perspectives as shown in the table 2:

Based on Time Need Effect

Change

anticipated vs. emergent elective vs. required beneficial

proactive vs. reactive discretionary vs. no-discretionary neutral

pre-fixity vs. post-fixity preferential vs. regulatory disruptive

Table 2: Change classification, after Motawa et al. (2007)

Other types of changes can be also briefly mentioned. For example, scope changes are a result of the client’s scope alteration. Such a change may be large to a degree that change the whole character of the work required under the contract. Another example is work regulation changes. As work regulations which are valid during the initial period of the project may be revised by the responsible governing agency later in the construction stage. Of course, the longer the project duration, the more it may be subjected to regulation changes.


2.6.2. CHANGE ORDERS

A change order is a contractual agreement required to change the agreed upon project scope within the post-fixity stage. It describes the changes to be done to the contract as well as to the project management plan (schedule, cost, methods etc.). Once a change order is approved and submitted it becomes a part of the project contract, by which the client and the contractor must legally abide. According to change orders project management plans, policies, costs or budget can be modified or schedule can be revised (PMI 2004). Such changes can be requested by any party in the project. However, all change proposals must be approved by the owner before change implementation. If the contractor will request a change order, it will typically be required to provide formal, written notice of the expected changed work. This written notice allows an owner to start change negotiations with the contractor. The purpose of these negotiations is to correct and accommodate the proposed change, as well as, to minimize its impact upon project costs and schedule. The result of such negotiations will be either the approval or the rejection of the proposed changes. From the construction law point of view, a written change order protects an owner from having to pay for unwanted work, and it protects as well a contractor by confirming changes that require modification of contract price and or completion time.

2.6.3. REWORK

Rework is a special and common type of changes in construction projects. It can be defined as a needed procedure of reproducing a planned and built element partially or completely with-out a need of a change order. It is needed because the product was firstly produced in a way, which is incompatible with the technical or contractual project conditions, i.e. has quality defects. Such defects can be found during the quality inspection or the audit process (CPRC 2004). Consequently, defect repair will be requested. Therefore, rework aims to repeat the work until a conformance between as-built and as-planned products will be achieved. As in construction the products have mostly physical manifestation, product rework is usually accompanied with the demolition of part or the entire product that has been already built. Several researchers indicated that the cost of rework in construction projects can be as high as 25-30% of the total project costs (cf. Ekambaram et al. 2005; Sun et al. 2006). Therefore, re-work has normally a bigger direct impact on the construction performance than other types of changes and it should be avoided as much as possible.

A taxonomy of rework suggested by Love et al. (1997) shows that root causes of rework can be categorized into different groups such as people-related (client, contractor, subcontractor) factors, design-related factors, and construction-related factors (figure 13).

Some of the rework causes related to the contractor are for instance:

Poor planning and coordination of resources,

Failure to provide protection to constructed works,

Multilayered subcontracting,

Use of poor quality materials by subcontractors.


Figure 13: Generic cause-and-effect diagram for rework, after Love et al. (1997)

2.6.4. CHANGE RIPPLE EFFECT

The ripple effect means that a change impact on a task or on an object may be propagated to other tasks or objects along the supply chain even in an unexpected way, see CIRIA (2001). The ripple effect of changes in construction processes can be attributed to the dependencies between tasks, elements, or resources. Emotional factors can also generate extra changes as a result of already done changes, e.g., the disappointment caused be different changes in the project can lead to loss in labor productivity and, consequently, to more changes. These dependencies may not be realized before making the main change. Therefore, additional sub-changes have lately to be implemented and extra cost and time will be wasted. The accuracy of the change impact evaluation may be improved using intelligent 3D models based on building information models, like IFC model. An example of the ripple effect of changes in a construction project is shown in figure 14.

Figure 14: The ripple effect of change in construction, adapted from CIRIA (2001)


In this example it is assumed that for technical purposes in a hospital project, a bigger room than what was planned is needed. This change is ascribed to the information that the medical device intended to be in the room needs bigger area for its service than what was planned. A wall move was approved as a solution for this problem. This change from the first glance is a simple one, which is accompanied by drawing change (plan change). After a deeper look and considering other related plans, secondary unexpected changes may appear. For example, the electrical team will need to change the route of cable tubes passing through the wall and the related drawings must be updated as well. The same may apply for plumbing works. Moreo-ver, the architect may find that the new decentralized window position in the perpendicular wall is not acceptable, which will be followed by as-built architecture drawing changes.

2.6.5. THE CHANGE MANAGEMENT PROCESS

As it was mentioned before, some changes can be anticipated, while others may occur unexpectedly. For the proac-tive type of change management, the generic change management flowchart in figure 15 is suggested. This flowchart benefits from the specifications of risk and change management process ex-plained previously. It starts by the iden-tification of the change that is needed. The same techniques that are used for risk identification can also be used in this step. After that, the assessment can be carried out to assist with decision making process. The assessment steps and techniques used in risk management process can also be used for this step. The decision of adopting a change can be internal (contractor side) for minor changes, i.e. change impact is within the change clauses limits of the contract. Otherwise, the change must be nego-tiated with the project client or his rep-resentative. Such negotiations can in-clude for example the necessity of the change, the options of making the change, the cost and time estimations and legal as well as technical approvals. If the client approved the change, then change plans and respectively change order should be done before the change can be carried out.

Figure 15: The generalized change management process, shown as a flow chart.


2.7. EXISTING WORK ON RISK AND CHANGE MANAGEMENT IN CONSTRUCTION

Most of the studied research work related to risk and change management in construction discusses the legal aspects of changes, i.e. building law perspective, such as claims and disputes, the effects of changes on labor productivity, the addenda, or the change orders (cf. CII(b) 1994; Elwert & Flassak 2008). As the building law aspect of risk and change manage-ment is not within this research scope, it will not be mentioned any further within this work.

Other research on change risk and change management in construction has tended to focus on the general factors and characteristics of the change, its causes, and its consequences. This resulted in standards and best practices in change management, like the practice guide and recommendations for managing project change effectively (CIRIA 2001), Change Project Management introduced by Construction Industry Institute (CII (a) 1994), and the Advanced Project Change Management System introduced by Ibbs et al. (2001).

Nevertheless, construction change management has been the focus of different ICT systems. For example, Ahmed et al. (1992) have developed an integrated environment for computer-aided engineering. This environment integrates a global database, several knowledge modules, and a control mechanism to systemize object changes. Spooner and Harwick (1993) developed a system with rules for coordinating concurrent changes and for identifying and resolving conflict modifications. Peltonen et al. (1993) proposed an engineering document management system for changes that incorporate document approval and release procedures. A change management system was proposed by Mokhtar et al. (1998) for managing design change in a collaborative environment. The model is capable of propagating design changes and tracking past changes.

Wasserfuhr and Scherer (1999) suggested within the frame of European research project ToCEE conflict management tools that can support the cooperative project design. They showed using an example how to solve a conflicting situation, due to an (unexpected) late design change. The conflict was detected using ToCEE change management tool developed on top of Autodesk’s Architectural Desktop. This tool enables to view and compare geometric conflicts of two model versions. After that the conflict can be registered in a Conflict Man-agement Server with the help of a dedicated Conflict Management Client. The conflict man-agement server stores the conflict data including all related references to processes and project data objects in a central conflict database which enables the monitoring of the conflict status, the maintenance of the data consistency and integrity and the notification of all actors in-volved in the conflict solution. Along with that, the process management system automatical-ly creates a new work task to negotiate the conflict with all involved actors. The coordination of the solution of the conflict will demand that the running workflow should be manually stopped and the needed re-design steps will be set and coordinated.

An information model to facilitate design coordination and management of design changes was introduced by Hegazy et al. (2001). Important dependencies between building compo-nents were represented by this model to help identify the ripple effect of changes between components. Also, a reporting system was used to view the history of all changes made by all disciplines. Another information model based on object-oriented concepts was introduced by Karim & Adeli (1999). Based on this model, “CONSCOM” a software system was developed. It covers construction scheduling, cost optimization, and change order management.


Charoenngam et al. (2003) developed a web-based change order management system (COMS) that supports documentation practice, communication and integration between different team members in the change order workflow. Standard web technologies were used and a change order procedure involving workflows, roles and actors, documents, records keeping, and a centralized database were developed. Motawa et al. (2007) introduced in their work the “Stability” concept to describe the possibility of changes in construction tasks. This concept was presented within a fuzzy-based change management system aimed at predicting the likelihood and impact of changes.

CCT is a change control tool introduced by Issac and Navon (2008). This tool creates requirement traceability through links between client requirements and the building design. This is based on the belief that the number and the impact of changes can be controlled by capturing client requirements accurately at the beginning of the project and through the requirement traceability that is build up afterwards. This tool notifies stakeholders if the proposed change has the possibility of delaying the project.

MCD was a three years research project (2001-2004) in England, the name stands for “Managing Change and Dependency in Construction Projects”. The project had the scope of developing a change management toolkit to assist the project teams to learn and improve their change management skills in predicating and managing changes (CPRC 2004). The conceptual architecture of the toolkit consists of two components, a Knowledge Component and a Support Component. The Knowledge Component contains a high-level generic change process, which consists of four stages: (1) startup, (2) identify and evaluation, (3) approval, and (4) implement and review. This change process interfaces with a project dependency framework. This framework has a hierarchical structure with four levels; the first level describes the key tasks of the generic change management. The other three levels are decompositions at increased degree of details. It defines standard procedures for managing changes in construction. The Support Component comprises a change prediction tool, which assesses the likelihood of changes occurring and simulates different scenarios of change options. This simulation can be carried out at the planning stage or at project execution stage.

A Project Rework Reduction Tool (PRRT) is developed by the COAA “Construction Owners Association of Alberta” to rate project performance against known rework-causing issues, COAA (2002). PRRT tool can be used to perform project “health checks” by making evaluations, rating key field rework causing factors, and by suggesting practical solutions to improve future ratings. The tool functions through the project ratings are given by a user in response to a multiple-choice questionnaire. The number and type of questions in the questionnaire vary due to the project’s position in the project life cycle. There are five different questionnaire formats in PRRT that are applied at different times in the project life cycle. The questionnaire results are mathematically weighted in order to calculate a periodic rating. A high periodic rating is indicative of a low tendency for rework.

A database to collect, record, and classify the disturbances in construction projects was introduced by Gehbauer et al. (2007). This database is based on MS Access and it contains four information areas: project data, disturbance registration, disturbance elimination, disturbance effects. The database was linked to an event-driven simulation-based planning tool in a trial to make a simulation of construction operation disturbances. Consequently, different created disturbance scenarios in the construction preparation stage will enable the planner to assess the temporal and monetary impact. As a result, it will improve construction processes before the execution has actually been started.


Lee (2006) tried to manage iterative change cycles in concurrent construction projects. For that objective, he suggested the Dynamic Planning and Control Methodology (DPM), which is composed of 4 elements:

Error and change management framework Proactive buffering strategy System dynamic-based construction project model Web-based error and change management tool.

DPM integrates several existing tools, e.g. network-based tools into its system dynamics model to increase its simulation capabilities. The web-based change management tool simulates the impact of iterative cycles based on the necessary factors. The generated output provides performance profiles that capture the impact of unanticipated events on the project performance. Schröder et al. (2007) developed a model-based information system to support the foundation engineering. This system enables the management of the project information and the project relevant documents on the basis of object oriented models. The main focus of the work was to support the early capturing of the engineering object current status and to enable a quick reaction to occurring risks.

2.8. DISCUSSION

There is generally a considerable level of complexity in construction projects. Using the work breakdown structure can help to clarify the hierarchical relationships between the tasks in the project and, consequently, to reduce the complexity. Moreover, constructions processes show dynamic features that can be ascribed to the high level of uncertainty in the construction projects. This uncertainty may lead to highly possible change risks in the construction processes. Risk management process aims to anticipate and handle, among others, the risks that may affect the project management plans in a proactive way. As the risk anticipation is based on incomplete information as well as because some undesired events happen suddenly, it is impossible to identify all potential change risks in advance. Therefore, some changes to the project management plan will be needed in the pre-fixity phase, while other have to be carried out later in the post-fixity phase, which is more costly and complex to be done. Fur-thermore, because of the nonlinear correlations between the building objects, the possible ripple effect of changes should be investigated and considered.

The related academic works carried out in the last two decades concentrate mainly on (1) establishing risk and change related standards and (2) considering the legal perspective of risks and changes in construction projects. Some researchers tried to use different ICT techniques to simplify dealing with some risk and change management aspects, such as ripple effect of changes, change order management, change prediction, and risks documentation and retrieval. However, an explicit investigation of the usage of the process-oriented knowledge to reduce the uncertainty and consequently to minimize the possibility of later corrective process changes is still absent.

Nevertheless, some ideas from the listed academic work in this chapter can be used as building blocks in the aimed approach of this research work such as (Gehbauer et al. 2007; CPRC 2004; PMI 2004) .

28 3 . BUSINESS PROCESS MODELING AND REFERENCE MODELING

3. BUSINESS PROCESS MODELING AND REFERENCE MODELING

Process modeling is not a new topic in construction academia and practice. It is used to represent graphically the developed project schedules. Several traditional modeling methods were used to serve this purpose, such as Gantt Charts, Network techniques, and Flowcharts. The models developed via these methods have been used as well, but on a limited scale, as knowledge storage means. Accordingly, it is common to find some schedule templates, process flowcharts developed in past project that can serve as a start point or a guideline for future projects. In the last decades the involvement of ICT technologies in mostly all business branches was a main interest of different ICT specialists, industry people, and academic institutions. This resulted in, amongst others, a new generation of process modeling methods, the so called Business Process Modeling (BPM) methods. In this chapter, an overview about the main concepts of BPM, its standards, and some BPM techniques will be given. The main focus in this overview will be on the exception handling in workflow systems and the workflow patterns, as these two topics have main relationships to the objectives of this research work. After that, a detailed literature survey about the usage of process modeling techniques in the academia and the practice of the construction sector will be presented. A general idea about knowledge management and the possible usage of process models as reference knowledge repositories is introduced. BPM is generally intended to model business processes rather than reference processes. Therefore, one BPM method (Event-driven Process Chains) that has the ability to model reference processes will be mentioned with extra details. Afterwards, the existing work about reference modeling in construction will be presented. The objective in this chapter is to define the needed requirements from BPM to model construction processes that are (1) flexible so they will suit different project contexts and (2) comprehensive so they will include all known exceptional aspects that may occur.

3.1. BASIC ISSUES

Information modeling, i.e. data-driven approaches, has been used traditionally as a starting point of development in information systems. The traditional data modeling relies on the creation of an Entity Relationship (ER) model11 to describe the data and several other models to capture the functionality and the logic of the system. Over the last two decades it has become clear that process term is equally important as data term and needs to be supported in a systematic manner. Therefore, the term process became a new productivity paradigm aiming at improving processes in the field of system engineering. This term has also started to be used in the field of software engineering as software process modeling. So, BPM became the base of new methodologies that support data collection, data flow analysis, and process flow diagrams. When a business sector will decide to move from the traditional methods to adopting BPM then it will be needed to re-formalize the understanding of current processes in a systematic way. Throughout this formalization, business processes are subjected to possible improvements, i.e. task removal, automation of some manual tasks, or the partial or even 11 Entity relationship model is a conceptual representation of data.

3 . BUSINESS PROCESS MODELING AND REFERENCE MODELING 29

complete reengineering of the process. Such automation will decrease the need of human participation in the process. Nevertheless, Harvey (2005) considers this effect of automation not as decreasing but as redirecting of the human effort to deal with hard problem instead of wasting time on trivial issues.

Classical methodologies that have emerged all over the 20th century such as flow charts, Gantt charts, Precedence Diagram Methods, etc. can be considered as the start point in BPM field. BPM replaced those vague diagrams that were drawn for business analysis with accurate models. These models use standard graphical flowchart-like language, as well as defined logic or XML-based description language in the background. This allows communicating with other services, systems, and users. Now, different process modeling tools are available in the market, which can help the clients to use different modeling methods. These tools can be classified to three types according to Keller (2006):

Visualization tools; can be used to illustrate process models graphically like MS Visio that offers drawing tools for different methods e.g., flowcharts, Unified Modeling Language (UML) diagrams, Express-G, Event-driven Process Chain (EPC) models.

Computer-aided Software Engineering (CASE) tools; support all the phases of software development, e.g. Rational Rose tool from IBM Corporation.

BPM tools; enable the modeling, optimization, and simulation of business processes, e.g., ARIS-Toolset from IDS-Scheer AG.

For the construction industry BPM can be considered useful for the following reasons:

Documentation; a developed business process model will be saved as one of the con-struction company documents, which can be retrieved when needed.

Simulation; can show an emulated progress of the modeled process, which will help to understand the needed steps and find the weak points in the process. Actually, the main current use of process modeling in construction is for simulation purposes.

Communication; instead of the classical flowcharts business process models can be used as a graphical representation. This can be used to communicate the ideas with other team people or project partners.

Optimization; as a process model offers simulation and communication capabilities, the underlying process is a subject to continuous improvements.

Software development; as BPM methods have their programming backgrounds, business process models can be used as middleware tier between process analysts and ICT experts to develop business related ICT solutions (Mendling and Nüttgens 2005).

3.2. BUSINESS PROCESS

A business process can be understood as a specific order of business steps, determined by a set of conditions across time and place. It has a start, inputs and outputs to reach a clearly defined end. Business process model is the result of mapping the current (as is) or a future (to be) state of an organization’s business process as well as the business environment. The modeled business process can be either a real-world business process as perceived by a modeler or a conceptualized business process (Mendling 2008). The steps of the process are called tasks and the occurrence of a process for special input is known as a business instance.

Business processes can be classified in three types, after (Weske 2007); those are private, public, and collaborative business processes. A private business process contains only


tasks that are performed within the organization. In such business processes all tasks that contribute to the process are represented. Public business processes represent only tasks that communicate with other business processes of other organizations or external indi-viduals. Public business processes share only those tasks with private business processes that exhibit a communication behavior. In a collaborative business process, two or more public processes are combined together to describe the behavior of all participants involved in a business-to-business collaboration.

In another classification, the tasks in a process can be system tasks, user interaction tasks, or manual tasks.12 Incidentally, before the sway of software, a business process was completely manual, i.e. paper-driven. Now, much of the processes are automated in several domains. Consequently, all relevant domain information is expressed in a structured, easy to analyze form. Therefore, the consistence of the models can be examined and the needed improve-ments can be realized.

3.3. BUSINESS PROCESS MANAGEMENT

BPM is the core of business process management. BPM is the human activity of creating a business process model. A business process model involves an abstraction from the real-world business process including only the relevant aspects which serves a certain modeling purpose. This model describes the business process on the conceptual level. The description of the business process on the operative level is done using a workflow model. A workflow aims to partially or completely automate a formally described business process.

Essentially, the management tasks related to business processes can be arranged in a life cycle. Many researchers have described the life cycle of business process management (van der Aalst and van Hee 2002; Muehlen 2004; Dumas et al. 2005). The life cycle introduced by (Muehlen 2004) comprises the management tasks of analysis, design, implementation, enact-ment, monitoring and evaluation. In this lifecycle (figure 16) there is a continuous attempt to improve the process by monitoring its implemented model and evaluating it against the requirements. The evaluation will confirm the need to improve the design of the process model.

Figure 16: Business Process Management Life-Cycle, after Muehlen (2004)

12 A manual task is performed by an organizational unit without involvement of an IT system.


3.3.1. PROCESS MODELING ABSTRACTION

Different concepts of abstraction are introduced to reduce the complexity in business process management. One type of abstraction is the separation of modeling process horizontally to levels and vertically to sub domains. Another type of abstraction is the aggregation, which addresses the objects granularity, from coarse-grained to fine-grained, within the same horizontal level of abstraction.

The horizontal separation presents the following three general levels of abstraction:

Instance level; shows the concrete objects, e.g., executed tasks, data value, and persons that are involved in the modeled business process.

Model level; the similar objects at the instance level are abstracted at the model level to reduce the complexity of business process scenarios, e.g., in object-oriented modeling similar objects are abstracted to one class.

Meta-model level; according to Weske (2007) a meta-model is the complete set of concepts and associations between concepts within a certain domain. A meta-model level is a description at the type level of a model. Thus, it can be said that several process models are systematic instantiations of one process meta-model.

In vertical abstraction discrete modeling sub domains are defined. This may include, but not be limited to, function, data, and organization modeling. In case of need, other sub domains may be defined as a part form the vertical abstraction. For example, in the Architecture of Integrated Information Systems (ARIS) the business process is divided into five views (organization, function, data, product, and control view), (see figure 17), which are required to provide a complete representation of the business process, Scheer (1999).

Figure 17: Horizontal and vertical abstractions in ARIS

3.3.2. WORKFLOW MANAGEMENT

BPM and workflow management presents different level of abstraction on process-oriented organizations. BPM covers the conceptual level of the process. In such representation, the process tasks can be manual and can be connected to any kind of resources, i.e. not only ICT resources. Workflow management represents the operative level of the process. It covers all the tasks that must be fulfilled in the fields of modeling, simulation, execution, and controlling of a workflow. These tasks can be undertaken using a Work flow Management


System (WfMS)13, which must be able to interpret the process definition, to communicate with the process participants, and if needed to call other applications. Therefore, a WfMS is suitable to deal with structured repetitive processes, which include a high degree of coordination (Klauer 2005).

According to their structures, workflows can be classified into different categories. Nastansky et al. (1994) suggested the following classification of workflows which can be applied also for business process models:

Unstructured workflows; represent one-off short-lived processes that consist of ad-hoc tasks. These tasks are difficult to be defined or to be structured in advance.

Structured workflows; such workflows describe a process, which is predefined. They are suitable for repeated unchanged processing and production processes such as credit application process. Therefore, they do not suit the construction projects because of the high degree of uncertainty and the uniqueness found in each construction project.

Semi-structured workflows; this type is a mixture between the structured and unstructured workflow types. Here, dynamic changes can be done to the workflow as ad hoc modifications. This type suits the uncertain nature of construction processes as these processes contain structured repeated part and ad-hoc exceptional parts.

3.3.3. BPM STANDARDS

Software and BPM communities developed in the last two decades many WfMS and BPM techniques according to their specific perspectives and the characteristics of their customers. Nonetheless, the scope and the customers of these tools were different so the presented solutions differed from the general scope of BPM. Therefore, the developers and users found that the creation of BPM standards is urgently needed to enable the exchange of process models between tools and to define a mapping between standard notations and execution languages. According to this, the Workflow Management Coalition (WfMC) was founded in 1993. It is considered now one of the most important standards developers in the Workflow market. One of its products is the XML Process Definition Language (XPDL), which is a standardized format to interchange process definitions between different modeling tools (WFMC 2010). There are other BPM standards came from different standard bodies like, Business Process Management Initiative (BPMI), Organization for the Advancement of Structured Information Standards (OASIS), or the Object Management Group (OMG). OASIS has introduced for example one of the strongest business process execution standards, i.e. the Business Process Execution Language (BPEL). It is based upon XML standards and Web Services to describe business processes for a runtime environment (OASIS 2007).

XMI was introduced by OMG as a standard for exchanging metadata information via XML. The Business Process Modeling Notation (BPMN) was introduced by OMG as a standard graphical notation to represent a business process visually and to enable business analysts and ICT developers to collaborate in the modeling of business processes as BEPL notation is complex to be understood by business people (OMG 2008). In spite of the benefits of the

13 Workflow Management Systems; are software systems that support the specification and execution of business processes.


BPM standards in unifying and harmonizing the BPM concepts, the existence of several BPM standards from different competitors instead of integrated products confuses the user and makes it also needed to standardize the similar products of these standards or to develop at least mapping and exchange methods between them.

3.4. PROCESS MODELING PATTERNS

In software engineering, software developers try always to make use of existing code snippets or libraries rather than starting every time from scratch. In view of that, many patterns in different ICT areas were developed; each one describes a practical solution to a real world problem. Each pattern shows how and when to apply this solution, and generates the desired design structure which recurs in practice (Gamma et al. 1995).

Accordingly, a pattern should include but not be limited to the following elements:

Name; a meaningful context-related title. Context; tells how the problem occurs and when the solution works. Problem description; statement of the problem and the intent of the solution. Solution; explains the solution structure.

In BPM, patterns were introduced as a solution to the problem that many processes are designed too quickly, without a strong foundation of previous experience. Therefore, some researchers were motivated to design patterns in BPM as such a foundation to aid in the creation of better processes (van der Aalst et al. 2003; Russell et al. 2004).

A BPM pattern can be defined as a formal cluster of process tasks, consisting of the specifications arranged according to a problem-solving strategy, possibly reusable by a specialized community. Nevertheless, in the context of business processes, not only the process patterns are valuable, but several perspectives can be identified, in which patterns can benefit the process modelers, for example:

Process patterns; concerned with establishing control flow dependencies among tasks Organization patterns; related to organizational entities Data patterns; related to data elements structure Domain-specific patterns; related to the properties of the domain

Van der Aalst et al. (2003) presented an initiative of 20 patterns specific to process control flow. These patterns are classified into six categories:

Basic control-flow patterns; the basic axiomatic control-flow constructs in most workflow languages. These are: Sequence, Parallel Split, Synchronization, Exclusive Choice, and Simple Merge pattern.

Structural patterns; Arbitrary Cycles and Implicit Termination patterns. Advanced branching and synchronization patterns; such as Multi-Choice or

Synchronizing Merge pattern. Cancelation patterns; based on the fact that in event-driven modeling an event may

cause to cancel a task or even the whole case, two patterns were introduced. Namely, Cancel Activity and Cancel Case patterns.

State-based patterns; consider focusing on the state besides tasks and events in workflow systems. As an example of such patterns is the Deferred Choice pattern.

Patterns involving multiple instances; these somewhat exotic patterns consider the


case when parts of the process need to be instantiated multiple times.

These patterns were described at the model level to be independent from concrete process languages. Therefore, each pattern may be represented in different modeling methods, depending on the degree of expressiveness of each one. It can be referenced to these control flow patterns in order to compare different BPM methods. This can help the process designer to determine different ways to assemble tasks. In view of that, these patterns have been used to evaluate several commercial and academic WfMSs, as well as, several standards such as UML and BEPL (c.f. van der Aalst and Hofstede 2005). These language independent patterns aimed to capture the different ways, in which data are represented and utilized in workflows. They can also be used for detailed comparison of the commercially available WfMS and BPM languages.

In his doctoral thesis, Russell (2007) emphasized that control flow and data management are now well addressed by existing languages and systems. Nonetheless, he has introduced 23 new control-flow patterns. Furthermore, he assured as well that less attention has been devoted to the resource perspective. Therefore, Russell (2007) introduced 43 resource patterns grouped into 6 categories, which are: Push, Pull, Detour, Auto-start, Visibility, and Multi resource patterns.

Other patterns can be of a great benefit to the developers, such as communication patterns describing how to communicate with external partners, introduced by Hohpe and Woolf (2004), as well as, the patterns describing how to manage recurring human workflow scena-rios, which are called human workflow patterns (Harvey 2005).

3.5. DYNAMIC ASPECTS IN WORKFLOW SYSTEMS

As it was mentioned before in this chapter, business process models and workflows represent the process-oriented perspective on organizations but from different levels of abstraction. A workflow can be defined as a formal described, completely or partially automated business process on the operative level. Business process models may include manual tasks and can in general have all kinds of resources linked to their tasks, i.e. not only ICT resources. In contrast to this, workflows do not consider manual tasks and their resources are only ICT-related. The dynamic aspects, associated with the modeled processes, were mainly considered on the operational process-oriented perspective. Workflows as task networks associate tasks by control-flow, data-flow, and resource-flow relationships. These objects and relationships may be changed dynamically to accommodate changes in the workflow and its environment. The dynamic events that change workflows are called exceptions within the WfMSs. An exception is defined as an abnormal event that arises in the run time of a workflow 14 . The occurrence of such an event may deviates from the planned behavior and lead to unexpected result or may prevent the progress of the workflow.

Similar to the classifications made for risks in project management literature, workflow exceptions can also be classified according to several perspectives. Luo et al. (2000) have classified exceptions in the following way:

14 In WFMSs literature there is a consensus on the definition of exceptions (Casati and Pozzi 1999; Luo et al. 2000; Dellarocas and Klein 2000; Kammer et al. 2000).


Known exceptions; those are already identified and included in the exception knowledge-base.

Detectable exceptions; those may not be identified but at least their occurrence can be noticed by the system.

Resolvable exceptions; those are identified or detectable exceptions that their consequences can be resolved using one or more of the exception handling methods.

Dealing with workflow exceptions needs the so called exception handlers. An exception handler describes the action(s) that workflow runtime component(s), or a workflow applica-tion is going to perform in order to respond to the exception. The handling of exceptions can be done, according to Luo et al. (2000), using at least one of three possible high-level strategies, cp. Risk treatment planning (2.5.2):

Exception masking; includes corrective actions such as restart, retry, reset, undo, complete, recover, ignore, jump, suspend the process, abort the process, or manual intervention “fool the system”.

Exception propagation; includes sending warnings out and the propagation of the exception.

Recording; includes recording the exception situation for future reference.

According to the classification of exceptions presented by Kammer et al. (2000), the exception changes can be to a specific instance of workflow, consequently, the general model remains the same. Otherwise, the changes can be evolutionary of general workflow model, affecting future instances of the work process as well.

Another intersecting classification can be obtained from the WfMS environment. As WfMS deals with business processes and need infrastructure to run and manage the workflows, the exceptions can be categorized to business process, WfMS, and infrastructure exceptions. The WfMS infrastructure may include, but not limited to, computer operation system, web connection, database connections and management systems. Infrastructure exceptions result from the malfunctioning of the underlying infrastructure that supports the WfMSs (Luo et al. 2000). These exceptions include, for example, computer operation system crashes, errors resulting from interaction with the web, database login errors, etc. Business process exceptions are related mainly to the specifications and the environment of the process itself. The infrastructure and business process exceptions are mapped to workflow exceptions (figure 18). This mapping means that an exception that occurs at the infrastructure or business process layer will trigger a mapped exception at the workflow layer. The mapping schema is adopted due to the heterogeneous nature of exceptions in business process and infrastructure levels. Accordingly, the workflow exceptions can be either (1) user defined exceptions that depend mainly on the business process exceptions or (2) system exceptions depend on the hard- or software malfunctioning.

In the scope of this research work, the interest is in the exceptions caused on the business process level. These specific exceptions are the possible risks and their corresponding changes that may occur in construction processes.


Figure 18: Exceptions mapping to WfMS exceptions

3.6. BUSINESS PROCESS MODELING TECHNIQUES

A BPM technique consists of a BPM language in conjunction with its respective BPM method. A BPM language guides the procedures of BPM by offering a predefined set of elements and relationships for business processes (Mendling 2008). A modeling language consists of (1) syntax, (2) semantics and (3) one notation at least (see figure 19).

The syntax; provides a set of constructs and rules to describe how these constructs can be combined.

The semantics; bind the constructs defined in the syntax to a meaning in a mathematical way.

The notation; defines a set of graphical symbols that are utilized for the visualization of the model.

Figure 19: Concepts of a modeling technique, after Mendling (2008)

The modeling method defines procedures, by which a modeling language can be used (Wand & Weber 2002). The result of applying the modeling method is a model that complies with a specific modeling language.

In the BPM domain, there are many modeling techniques that suit different requirements of the organization’s processes in different management levels. For workflow design purposes there are popular techniques for process modeling, for example, IDEF0 “Function modeling method” (Mayer et al. 1992), Event-driven Process Chains “EPCs” (Scheer 2000), the Activity diagram model within UML (Fowler 2004), and Business Process Modeling Notation “BPMN” (OMG 2008).

Another group of process modeling techniques is the one used to describe the state of the business process. Instead of the process control flow represent these techniques the behavior of the process objects. Thereby illustrate the nodes of such a model the possible states of the process objects and the transitions, which can trigger the state-change actions. The UML state diagram (Alhir 1999) is an example of such methods.


3.6.1. FORMALIZATION DEGREE OF A PROCESS MODELING TECHNIQUE

According to the degree of formalization in their syntax and semantics, process modeling techniques can be grouped in three types:

Informal techniques: their languages rely only on the textual description of a natural

language and do not follow any formalized schema. A business process descriptive

report is an example of such techniques.

Semi-formal techniques: in such techniques the syntax of the modeling language is

defined, i.e. the elements of language and the rules describing how to combine these

elements. In contrast, the semantics of the language is not defined at all or just

partially defined. This means that there are difficulties to link the syntax’s elements to

mathematical concepts. In other words, a model produced by such a technique can be

interpreted differently from one person to another. The execution of such a model in a

WfMS is not directly possible (Klauer 2005). An example of such techniques is EPCs.

This can be ascribed in this technique to the non-local semantics of the OR connector,

i.e. the decision of the connector case cannot be taken without non-local knowledge

(Weske 2007). Such non-local knowledge is not available for machines and therefore

such models are un-executable. Nevertheless, these methods can be used as starting

point for the implementation of computer-supported information systems.

Formal techniques: the syntax and the semantics of the language of such techniques

are defined explicitly and are not ambiguous. Petri Nets technique, for example, has a

formal process modeling language. The semantics of Petri Nets is well defined and not

ambiguous as the graphical syntax has an equivalent mathematical formalization, as

well as, the activation of tasks in a business process is based on local knowledge only

(Weske 2007). This allows for the representation of the process model on the technical

level and the direct implementation of computer-supported information systems.

3.6.2. EXISTING BUSINESS PROCESS MODELING TECHNIQUES

The techniques that will be introduced here are divided into two groups. The first one includes techniques that are known and used in construction to model and manage construction processes. These techniques can be found, as methods or services, in different software, but in their structural background they do not have any ICT-support or interface. The second group includes the BPM techniques that were originally developed by ICT-specialists to serve ICT-objectives. Accordingly, the structure of such techniques includes some ICT concepts and has some interfaces to different ICT tools.

3.6.2.1. TRADITIONAL PROCESS MODELING TECHNIQUES

Several traditional modeling methods are still used in the construction project management to plan and communicate the construction processes. These methods are relatively easy to handle besides construction engineers are used to implement them over decades in construction work. An overview about some of the common modeling methods will be given in the following:


GANTT CHART

Gantt chart is the most widely used type of bar charts in construction management practice to model the project schedule (Uher 2003). To establish a Gantt chart, the construction process must be broken down to tasks, similar to functions in BPM methods. Different types of task relationships (start to start, end to start, start to end, end to end) can be shown on the Gantt chart to increase the efficiency of this method. Gantt charts are supported by almost all the project management software in the market, such as MS-Project from Microsoft or Primavera p3e from Primavera Systems. Although this method is popular because it is clear and easy to use and read, but the clearness of it will be reduced considerably as it will describe a large project with many tasks.

CRITICAL PATH METHOD

Critical Path Method (CPM) is a network model for project management used for scheduling the project tasks developed in the late 1950`s. It provides a graphical representation of the sequence and the interdependency between tasks and enables the calculation of the project duration. This method needs a list of the tasks required to complete the project, concluded from accepted level of work breakdown structure. Also, it needs the estimated duration that each task will require to be completed and the dependencies among these tasks. The most important result of the CPM method is the critical path of the project. The critical path is the sequence of tasks from the project start to the project end, which has the longest duration, each task on this path has a zero total float. Any delay in any task on the critical path will delay the whole project by the same amount. However, CPM is a deterministic method that uses a fixed time estimate to calculate each task’s duration. Consequently, if a mistake is made in the estimation the whole analysis could be flawed.

PROGRAM EVALUATION AND REVIEW TECHNIQUE

Program Evaluation and Review Technique (PERT) is a network model for project management developed also in the late 1950`s. It solved the fixed time estimate problem by CPM as it allows for randomness in task completion time with assumed probability distribution, (Uher 2003). PERT has the ability to deal with uncertainty in task completion time. For each task, the model includes three time estimates (1) optimistic time O, (2) most likely time M, and (3) pessimistic time P. Moreover, PERT assumes a beta distribution for the time estimates. For a beta distribution, the expected time for each task, which will be shown on the network diagram as task duration, can be calculated using the following formula:

Expected time= 4

6

The relationships between the tasks are only from end-to-start type. The analysis of such network model will give the following results, (see figure 20):

The critical path of the project

EST, Early Start Time of each task

LST, Late Start Time of each task

EFT, Early Finish Time of each task

LFT, Late Finish Time of each task

TF, total float of each task, equals zero for critical tasks.


Figure 20: CPM network model

Although this method has a probabilistic time estimate, it has still the disadvantages of being

deterministic modeling method as it imposes a fixed, unchangeable flow of tasks. It is also

assumes, like the CPM method, unlimited availability of all needed resources by all tasks.

CRITICAL CHAIN PROJECT MANAGEMENT

Critical Chain Project Management (CCPM) is a method of planning projects based on the

algorithms of the Theory of Constraints (TOC). It emphasizes the resources and resource

limitations to control the project execution (Leach 2005). Accordingly, it solves the weak

point in CPM and PERT related to task orientation and resources negligence. Actually, if a

project will have unlimited resources then CCPM will be identical to CPM. A critical chain

schedule takes contingency buffers that were scattered among the tasks and concentrates them

at the end of the critical path and where other paths feed the critical path. This method showed

that the use of the flexible size and location of buffers could be more effective in protecting

the planned performance than what CPM or PERT can offer.

3.6.2.2. MODERN BPM TECHNIQUES

In the following, the main concepts of three BPM techniques will be introduced. Each one

supports the design, the planning, and the implementation of business process models

differently. These techniques are: Petri Nets, Yet Another Workflow Language (YAWL),

Event-driven Process Chains (EPC).

PETRI NETS

Petri Nets is a formal abstract15 modeling and simulation technique. It was developed in 1962

by the mathematician Carl Adam Petri (Petri 1962) as a formal approach for modeling and

analyzing processes. This approach has a graphical representation as well as an equivalent

mathematical formalization. Petri Nets is suitable to model dynamic systems with a static

structure. A Petri Net model consists of places and transitions. Places and transitions can be

linked by means of directed arcs. A link between two places or two transitions is not allowed,

i.e. the link must be either from place to transition or from transition to place. Places may

contain tokens (see figure 21).

The static structure is represented by the Petri Net while the dynamism by tokens

allocation through the Petri Net. Accordingly, the distribution of the tokens among the places

can change according to the defined rules while the structure of the Petri Net stays fixed (van

15 Abstract means here that it does not cover all aspects other than the functional and process perspectives of a business process.


der Aalst and van Hee 2002).

The state of the process is expressed by distribution of token amongst the places in the Petri

Net. This state can be described using vectors, for example in figure 21 it can be described

using the vector (2, 0, 0). This indicates that there are two tokens in the first place and no

tokens in the second and third one. Transitions are enabled to fire when there are enough

tokens at each of its input places. The first transition (no.2) in figure 21 will consume one

token from the input place (no.1) and produce another token in the output place (no.3). The

new net state can be described now using the vector (1, 1, 0). In the same way, the transition

will proceed until the final state of this net (0, 0, 2) will be reached, now no further firing is

possible.

One of the main shortcomings of this technique is the limited information presented by the

tokens, as they do not provide any data except their current existence in some places in a Petri

Net. This, amongst other things, causes that the classical Petri Nets approach was unable to

satisfy different needs of process modeling domains. Therefore, it was necessary to enhance

this approach by adding some extensions to it. A Petri Net that includes one or more of these

extensions is called a high-level Petri Net. The most important extensions are the color, time,

and hierarchy extensions. Using them, the modeling of larger and more complex processes

was possible.

Color extension: in the classical Petri Net, tokens are identical as it is impossible to

distinguish between them. However, each token has its own value or set of values that

distinguish it from other tokens. By “valuing” tokens, they are given different colors.

Time extension: as the classical Petri Nets do not allow the modeling of “time”, it is

necessary to include relevant information about the process timing in the model. By

the time extension each token receives a timestamp as well as a value. This indicates

the time from which the token is available. The tokens are consumed according to the

first-in, first-out basis. Therefore, the token with the earliest timestamp will be the first

to be consumed and the transition with the earliest enabling time that fires first.

Hierarchical extension: highly detailed processes can be excessively large to be

represented in one net. Also, a single net will not serve the different degrees of granu-

larities needed in the model in different organizational levels. The hierarchical

extension permits the initiation of subnets on the firing of a transition (Havey 2005).

A new Petri Net building block, shown graphically as double-bordered square, was

introduced in this extension to represent a sub Petri Net process that can, in turn,

include sub-Petri Nets. Using such building blocks, a Petri Net can be structured using

either a top-down or a bottom-up approach.

More details about Petri-Nets extensions can be found in (Franz 1989; van der Aalst and van

Hee 2002).


Figure 21: A classical Petri Nets

YET ANOTHER WORKFLOW LANGUAGE

Yet Another Workflow Language (YAWL) is a process modeling language based on control-flow patterns (cf. 3.4). It was defined by van der Aalst and ter Hofstede (2005) as the first workflow language that supports all these patterns. It is supported by a software system that includes an execution engine and a graphical editor (YAWL 2008). YAWL takes Petri Nets as a starting point and adds new symbols in order to support all control-flow patterns. These new symbols support AND, OR, and XOR splits and joins, as well as multiple task instances (see figure 22).

Figure 22: Notational symbols of Yawl, after van der Aalst and Hofstede (2005)

YAWL offers a comprehensive support for the control flow patterns. It has a XML based model for data definition and manipulation based on XML schema, also plug-in interfaces for connecting third-party web services with the system. Notwithstanding this, Havey (2005) hinted that BPMN and BPEL have still a greater traction than YAWL in the industry, as all-patterns-support is but only one of many factors used to choose the right BPM technique.

EVENT-DRIVEN PROCESS CHAINS

Event-Driven Process Chains (EPC) is a method developed by Keller et al. (1991) within the frame of the Architecture of Integrated Information Systems (ARIS) to model business processes. The ARIS Architecture is often denoted as the ARIS house, as shown in Figure 23. It contains five different views to represent a vertical abstraction of business processes (cf. section 3.3.1). These five views are:

Function View; represents the functions of an enterprise needed to achieve its


objectives and their relationships. In general, one function might be a part of a superordinate function at the higher level. At a lower level of abstraction, subordinate functions are associated together to form a superordinate one. In this way, functions can be hierarchically decomposed to the desired granularity level.

Organizational View; describes the organizational structure of an enterprise at a type level and at an instance level (Weske 2007).

Data View; describes business relevant data objects that are manipulated by functions during business process execution. The data view is expressed using the ER data model.

Product/Service View; describes the outcome of business processes, i.e., the products and services the enterprise generates. These can be physical products, as well as intangible products. Each product has to be processed by several functions. This processing appears pro function as input-state product and output-state product. The function dependencies can be built upon that, for example, the output-product of function (a) is needed as an input-product of function (b). This means that function (a) should be logically carried out before function (b).

Control view; provides linkage between the models in the different aforementioned views. Functions, for instance, are associated with the organizations that are responsible for carrying out these functions. Correspondingly, data objects are associated with functions that need them or even produce them. In this way an integrated view of the business processes of an enterprise can be achieved.

Figure 23: Interdependencies of the business views, represented using the ARIS house, after Scheer (1999)


The combination of all the views will produce an EPC16 diagram, which is illustrated in the control view in figure 23. EPC can be identified as a semi-formal modeling language that contains a visual notation, which consists mainly of events, functions, logical connectors, and control flow. It describes business processes by creating a chronological sequence of events, functions and their logical interdependencies using logical connectors. This notation can be extended by adding the related organizational and data elements to the classical diagram.

Functions in EPC represent the tasks to be executed. They are the active elements in EPC as process decisions are made via functions. A function is represented as a rounded rectangle (see figure 24). An EPC function can be refined into another EPC model, unless it is a leaf function in the function hierarchy. EPC is called in this case a hierarchical EPC. A flat EPC model has only one level and cannot be detailed to another EPC model. Events are the passive elements in EPC, i.e. no decision is made using an event. It has the role to describe the pre-state or the post-state of a function. Events do not consume time or costs within the process. They are represented in the EPC process model as hexagons. The control flow is graphically represented as an arrow connecting events, functions, and connectors with each other creating chronological sequence between them. Because EPC is an event-driven modeling method, it has no function-function or event-event connections since each function follows a generating event and in the same time it is followed by a generated event.

The logical relationships between the elements in EPC (function-event, event-function) are shown using connectors. The types of connectors used in EPC are:

AND connectors; using opening AND connector a control flow can be separated into two or more outgoing control flows, also more than one incoming control flow can be joined in one control flow using closing AND connector. This type of connectors mod-els the parallelism case among processes.

Inclusive OR connectors; an opening OR connector has one incoming control flow branches to more than one outgoing control flow. At least one outgoing control flow can be activated. Closing OR connector has more than one incoming control flow, one or more of them will be activated, merged in only one outgoing control flow.

Exclusive OR (XOR) connectors; in branch XOR connector, the connector has one incoming control flow and more than one outgoing control flow. Only one outgoing control flow will be activated. In merge XOR connector there are more than one in-coming control flow, only one of them will be activated, and only one outgoing con-trol flow.

Figure 24: Elements used in EPC

16 Actually the diagram that contains elements from all the views of ARIS House is called eEPCs, referring to the extended Event-driven Process Chains. In this work EPC refers also to the eEPCs.


There are several rules that direct the usage of the EPC elements and guide model designers to design lawful EPC process models, such as:

Only connectors are allowed to branch, nor events neither functions.

Split connector of type (Event-to-Function) cannot be of type “XOR” or “OR”, as an event is a passive element. So it cannot be used to make decisions but only to trigger parallel functions using AND connector.

Logical connector should match, meaning that an opening XOR serving as a branch should be closed by another XOR connector. The same rule applies to fork/join using AND connector and OR connector.

The heterogeneity of interchange formats introduced by different BPM techniques has motivated the specification of an EPC Markup Language, named EPML, as a tool-neutral interchange format. EPML is supported by the processional BPM tool Semtalk17 and also by the open source initiative EPC Tools (Cuntz and Kindler 2009).

EPML was presented by Mendling and Nüttgens (2005). It captures the essential concepts of EPCs. These include, for example, function, event, connector, and arc elements, as well as vertical EPC abstraction using hierarchical functions, in addition to the horizontal decomposition using interface elements.

As it is shown in the example in figure 25, <epml> is the root element of an EPML file. This root element has at least the essential attributes, namely, EpcId and EPC Name; also it may have child elements. These child elements are the EPC elements mentioned before in this chapter. The EPML notation includes also, but is not limited to, the following points:

Each child element of the root element in EPML has a unique ID as an attribute of this element.

As EPC has a graphical notation, the data related to the graphical properties of the modeled element has to be included in the EPML file. This data is stored in the <graphics> child element of each EPC element and contains position and size information of this element. Extra information that includes fill, line, and font etc, can also be comprised.

A function or an event must have a name. The name is stored in EPML in a <name> element, which is, in turn, a child of a function or an event element respectively.

Each arc is represented as a child element of the <root> element. It has also a <graphics> child element including a <position> element with the start and end anchor points of the arc as attributes. <arc> element may also include the position of arc bending points, if any. The elements dependency data of an EPC model are also included within the <flow> element in the shape of end to start relationship. <flow> is a child element of the <arc> element and it has two attributes: (1) a source attribute has a value that represents the ID of predecessor element, i.e. the element that contains the start anchor point, (2) a target attribute has a value that represents the ID of successor element, i.e. the element that contains the end anchor point of the arc.

17 http://www.semtalk.com/


Figure 25: Translation example of an EPC graphical model to EPML model (based on EPC Tools)

3.7. EXISTING WORK ON THE USE OF BPM IN CONSTRUCTION

The use of modern BPM techniques in construction management remains basically limited to the academia and research environments. In large construction companies the processes may be well documented and standardized, but, unfortunately, without ICT-support for integrated process management (Gehre et al. 2008). Actually, construction companies did not have yet demonstrated an encouraging acceptance of these techniques. In spite of that, BPM was addressed to be necessary to gain ISO 9000 Certification in construction (Issa and Cox 1996). As a result, it can be generally said that there is no explicit support yet to the process-centered modeling in the construction practice on a considerable scale.

The developed process modeling methods in the construction academic sector can be classified to two types. The first type shows that some researchers tried to develop their own modeling methods either from scratch or based on other methods developed only for the construction domain (Halpin 1977; Paulson 1987; Halpin and Martinez 1999; Sharifi et al. 2006). On the other hand, ICT-methodologies and standards that influenced other industries seemed to be applicable, maybe indirectly, in the construction industry. Therefore, construction specific requirements had to be considered in such adoption. Accordingly, other researchers used process modeling methods, which were designed and adopted by other manufacturing domains, to develop methods that suit construction domain characteristics.

One of the early efforts of construction project modeling research area is CYCLONE (CYCLic Operation Network), which was developed by Halpin (1977). CYCLONE presents a system modeling technique, which can illustrate the system graphically as a network contains deterministic and stochastic variables. Based on the CYCLONE concept several works were


introduced, such as (Paulson 1987; Halpin and Martinez 1999; Sharifi et al. 2006).

Based on the object-oriented concepts, several process modeling and simulation systems appeared in construction management. For example, Construction Object-Oriented Process Simulation system (COOPS) is a discrete object-oriented simulation method developed by Liu and Ioannou (1992). The basic COOPS modeling elements are nodes, links, and attachments. These elements can be placed in multi-level network according to priority rules. This network illustrates the system model, which can be connected to knowledge-based systems.

The Knowledge-based Construction Integrated Project and Process Planning Simulation System (CIPROS) is an object-oriented method which was developed in Michigan University. This system enables the integration of the drawings and time plans in the model using extendable library (Tommelein et al. 1994). Based on these object-oriented systems different construction schedule simulators in USA were developed.

All the mentioned systems were described on the process level. The modeling on the project-level is theoretically possible, but it is faced by some difficulties because of the big number and complexity of processes, which made the practical application of the modeling on this level ineffective. Although, some attempts of modeling on the project level appeared. For example, Sawhney and AbouRizk (1996) developed a hierarchical method, named HSM, based on CYCLONE technique for the modeling and simulation on the project level. HSM provided a library of modular processes which can be used to develop a complete project model. Also, Hajjar and AbouRizk (1998) presented an approach aimed to facilitate the adoption of simulation by the construction industry. This approach summarized the developing and implementing simulation-based tools at a number of construction firms. The implementation of these simulation tools was based on a visual object-oriented modeling environment.

Petri Nets was one of the first ICT-methodologies adopted in the construction industry to help in decision making for complex construction processes. It played an important role over the last 30 years in the modeling for simulation purposes, in research and even in practice, of different aspects in the construction management. Franz (1989) proved that it is possible to use high-level Petri Nets with some modifications to analyze and simulate complex construction processes. Also, Sawhney et al. (1999) have used Petri Nets for the modeling and simulation of a ready-mix concrete plant. Moreover, Khneisseh (2005) suggested a method based on colored Petri Nets to evaluate and optimize business processes in construction industry. In an effort to integrate simulation tools with other construction system, Chahrour (2007) developed a simulation environment, based on Petri Nets, that is connected to a product model and CAD-System. This tool was used to prove the feasibility of construction earthmoving operations. Petri-nets based simulation in construction practice was used but on a limited scale. For example, it was used in the construction project (Postdamer Platz, Berlin) to simulate earthmoving, concrete supply, and other logistic operations. The objective of the simulation was to make capacity and schedule related prognoses, see (Kantelberg 1998).

Klein et al. (2000) argued that contemporary workflow management systems lack needed flexibility and have problems in dealing with change. Therefore, such systems will not be suitable for the construction processes. As the progress of a construction project is based on


pre-specified causal relations, Wamelink et al. (2002) have suggested Case-handling as the most suitable modeling method for the construction processes as it is driven by data flow instead of solely driven by control flow. Accordingly, FLOWer (Pallas Athena 2000), a Case handling system, was used to model some project manuals belong to Heijmans, a Dutch construction company. These manuals contain standard documents and schedules to execute parts of the complete construction process (Van der Aalst et al. 2003).

Scherer (2006) suggested an integrated dynamic platform for product and process modeling for the improvement of the assessment of risks in construction projects. Huhnt et al. (2006) argued that the manual creation of a schedule is an error-prone and time consuming process. Therefore, they presented a semi-automate modeling technique to generate construction schedules, where the technological interdependencies between the construction tasks are treated as results of relational algebra algorithms. Accordingly, the authors guarantee the logical correctness and completeness of the resulting schedules. However, these schedules should be reviewed and adapted to consider the other additional restrictions, such as resource limitations.

Modeling the collaborative processes in construction had attracted the attention of several researchers. As it was mentioned before, in a construction project several partners have to work collaboratively to achieve the agreed project objectives. From that the importance of the collaboration in construction appears. In the German research project, named the Architecture of Collaborative Scenarios (ArKoS) 18 , an architecture, which builds upon the ARIS methodology, was suggested for the integrated support of cooperation- and coordination-intense cross-enterprise business processes. The industry-indifferent framework provided a generic solution concept, which is transferred subsequently into an industry-specific reference model for the construction industry. The construction industry served in this project as an application domain because services that require the coordination of numerous enter-prises are generated in large projects exactly in this industry. At the same time the enterprise networks of such construction projects are characterized by high dynamics and fluctuation. A separation between local and global process knowledge was suggested in ArKoS as a three-tier framework (see figure 26). The reason is that the partners that cooperate in one project can be competitors in other projects. Therefore, the process information security on the pri-vate level must be insured, see also Adam et al. (2005). On the other hand, the global know-ledge is available for all participants. The main benefit is that the partners can provide access to relevant information, described as global knowledge, and at the same time are able to pro-tect their business secrets. The local knowledge is contained in “process modules”, which are understood as abstractions for more detailed subprocesses, encapsulating sensible process information. Private process modules are linked within the collaborative scenario using the ArKoS concept "process interface". For the collaboration partners only the data at such inter-faces, that is the input or the output of the respective process modules, are visible and relevant for the realization of the collaboration. The third tier addresses the collaborative business ex-ecution, in which the integration of different applications and platforms is established.

18 http://www.arkos.info/


Figure 26: The ArKoS three-tier framework

3.8. REFERENCE PROCESS MODELING

In BPM the term “reference model” is used to refer to the generic model that can be used as means of knowledge management irrespective of a certain case. It can be defined as an information model, which will provide ready best-practice solutions. These reusable solutions included in the reference model help the business people to rely on as much as possible existing models rather than systematically designing a new one from scratch. It can be also the case that the use of the reference model-inherent knowledge will not give a ready solution but it will offer an initial solution to start with, which can be extended and adapted to suit the case at hand. A reference model can cover organizational, technical, and structural informa-tion in a specific domain.

The usefulness of a reference model appears in:

The ability to reuse it, maybe after some treatment, to model domain cases.

Its use as a benchmark to compare domain instances with it, and to define if there are any deviations.

The design of a reference model starts by building a process model that describes a specific case. After that, the process model should be extended to cover all known cases that may be faced in the process within this domain. In view of that, the business process model should be comprehensive enough. This can be done by including the best domain-practice gained from performing this particular business process. This means, the reference model will represents


the collected process knowledge. Moreover, the reference model should model adaptation19 functionality, i.e. it must be possible to adapt it to the special situation of each case.

Fettke & Loos (2007) identified four needed views that a reference modeling should be consistent from:

Reference modeling language: a modeling language defining a number of modeling elements and the rules to combine these elements to represent operational systems.

Reference modeling method: the method defines an approach for the systematic implementation of the modeling language elements to design and use a model.

Reference model: the result of the implementation of the method is the reference model.

Reference modeling tools: modeling tools are integrated components of the modeling context, e.g. ARIS-Toolset20.

Unfortunately, the traditional modeling languages are developed to describe individual models and not reference models, so they lack conceptual support for the adaptation to different needs and provide no decision support for model variation.

In the following an overview about the knowledge management process in general will be introduced as a start point to build a reference model. After that, the life-cycle of business reference models, which is derived from the life-cycle of the knowledge management process, will be presented. Then, an extension to the BPM technique EPC, that helps to build a reference model as a configurable one, will be detailed.

3.8.1. KNOWLEDGE MANAGEMENT

Knowledge exists in implicit way in all fields and is enhanced by the work experience. It is not shareable as it is present only inside its knowing subject. Nevertheless, it is needed to obtain and formulate part of this knowledge and later to reuse it by other people to extend their knowledge. For this reason, it is needed to transform the needed knowledge from implicit to explicit one.

Knowledge management can be supported in different ways using information and communi-cation systems. For the notation of knowledge it is possible to use “Predicate Logic”, “Pro-duction rules”, and “Semantic Nets” (Keller 2006).

Knowledge is a subset of information and it results from applying rules to extract, filter, format, and process a related part out of the available information. Data, specified in some conceptual context, i.e. expressed in a structured format, represents the information available in a specific field. The data are one or more values of an observable, measurable, or calculable attributes. Therefore, knowledge management can be defined as the process of capturing and organizing implicit work-related information of the workers within an organization and storing it in an explicit way to make it available to others.

Knowledge management deals with the possibilities to control the knowledge-base of an organization. An organization’s knowledge-base should contain the information needed in this organization to deal with its different tasks. According to Probst et al (2006) the knowledge management process contains the following components (see figure 27): 19 Adaptation, Configuration and Adjustment terms are used interchangeably in this work in order to keep the original naming given in the literature of the different domains. 20 ARIS-Toolset is a software-tool developed by the German software company IDS-SCHEER


Knowledge objectives; give the sense and the direction of the knowledge management process

Knowledge identification; means to gain information about the already known knowledge

Knowledge acquisition; means to gain knowledge from external means

Knowledge development; can be classified to individual knowledge development and collective knowledge development

Knowledge sharing/allocation; uses a technical infrastructure to enable some knowledge from the whole organization’s members or to keep other knowledge undisclosed for the majority and only authorized members will be able to access it.

Knowledge utilization

Knowledge preservation; saves and updates the knowledge.

Knowledge evaluation

Figure 27: The components of the knowledge management process, after Probst et al (2006)

3.8.2. THE LIFE-CYCLE OF A REFERENCE PROCESS MODEL

According to Fettke and Loss (2004), reference modeling can be structured in two cyclic processes (figure 28) to represent the steps the reference model passes through from the design to the application:

The design process, with an objective to design and build a particular reference model. The process will start by defining field of interest to be modeled. After that, the refer-ence model related to this field will be developed. Then, the reference model will be evaluated to insure its quality. Afterwards, revisions and improvements on the model can be made.

The application process, with an objective to reuse the reference model for the development of a particular enterprise model. This process starts by selecting the relevant part of or the entire reference model to reuse. Subsequently, the reference mod-el must be adapted to suit the special parameters of the user’s case. Next, the resulting model should be integrated with other used models to have a complete view about the case at hand. This all will be followed by the utilization of the model.


Figure 28: The life-cycle of a Reference Process Model, adapted from Fettke & Loss (2004)

3.8.3. CONFIGURABLE EVENT-DRIVEN PROCESS CHAINS

As it was mentioned before, the traditional modeling languages are developed to describe individual models and not reference models. Rosemann and van der Aalst (2003) proposed Configurable EPC as a reference modeling technique that can be considered as an extension to the normal EPCs technique. In this extension new elements were added to the classical EPC to provide for the potential adaptation alternatives supposed in reference models.

C-EPC extends regular EPC to allow for the specification of configuration connectors and configuration functions in a reference process model. In this extension of normal EPC, configuration patterns have been identified and classified. A configuration pattern highlights distinguishable configuration alternatives. These patterns can be classified in the following types:

Configurable Functions; that may be included (ON), skipped (OFF) or conditionally skipped (OPT). It is represented in the EPC model as grey highlighted rectangle with bold border (see Figure 29).

Configurable Connectors; that may only be mapped to a connector type that restricts its behavior (Rosemann and van der Aalst 2003). C-OR connector for example can be configured to normal OR, normal XOR, normal AND, or mapped to a single sequence of events and functions SEQ. All configuration constraints for the configurable connectors are summarized in table 3.

Sequence Relationships; that connect variation points with either mandatory rules (configuration requirements) or optional rules (configuration guidelines) to facilitate the configuration of the model.

Figure 29: Configurable patterns within C-EPC


Nevertheless, some syntactical problems may arise in the EPC models due to the configuration. This and the correct translation of configured C-EPC models into lawful EPC were addressed by (Recker et al. 2006).

SEQ AND XOR OR

X X X X ORC

X X XORC

X ANDC

Table 3: Constraints for the configuration of connectors in a C-EPC, after Mendling et el.( 2005)

The configurable modeling concept is illustrated in the following example in figure 30. There are three configurable functions in the configurable EPC model, in the left part, and one C-OR connector. Function A and the C-OR are connected together using a requirement constraint, it states that if the Function A will be skipped then the C-OR will be mapped into a normal AND. Also the other two functions are connected together using a soft constraint “a guideline”, which state that if the Function D will be adopted then E should be adopted also and vice versa. In the right part of the figure 30, one possible configured EPC is shown, which is mapped from the configurable EPC by skipping the Function A, therefore the C-OR is configured to an AND connector. Also Function D is adopted as a normal function thus Function E is adopted as well.

3.8.4. REFERENCE MODELING IN THE CONSTRUCTION SECTOR

Construction processes differ from other production processes in their dynamic and unique characters. Although, according to Egan (1998) more than 80% of construction processes are repeated. Moreover, much repair and maintenance work also uses repeated processes.

Figure 30: Mapping example from configurable onto configured EPC, after Recker et al. (2006)


Consequently, it should be possible to standardize the similarities between the processes that produce the same deliverable in the shape of a reference model. Consequently, a reference model represents a process-oriented knowledge repository about the production of a specific deliverable.

Actually, knowledge standardization is not a new topic in civil engineering, although it was not a focus to structure the construction information in process-oriented way. Several contributions tried to document the construction knowledge collected from different projects. Such documentation aimed to reuse the available knowledge in order to save time and costs as well as to reduce the error rate in all the project phases. For example (Alexander et al. 1978) suggested a Pattern Language for building and planning based on natural considerations. They gave an overview of some 250 reference patterns that are the units of this language, each consisting of a design problem, discussion, illustration and solution. By understanding recurrent design problems in the environment, the user can identify extant patterns for the design projects. In the construction practice the knowledge can be found in implicit way often in term of forms, diagrams, tables but rarely in process-oriented way. For example, STLB-Bau21 is a comprehensive database in the German construction software market. It contains actual ready-made texts for the technical specifications of the construction services. It offers an Application Programming Interface (API) to enable using its data in project management software for tendering, awarding, and accounting purposes.

It is also still common to standardize construction schedules as templates including a part or complete project schedule network. For example, according to Wamelink et al. (2002) the Dutch construction company “Heijmans Bouw” uses the so-called “Project Manuals” as a basis for its projects. These manuals contain standardized schedule plans for different construction phases, e.g. execution preparation and execution phases. However, these manuals do not offer the needed flexibility to arrange the schedule plans according to the case specifications.

WBSs that are developed in past products can be used also for actual similar construction products. Consequently, WBSs templates can be built that represent task or deliverable-oriented WBSs of frequently needed products. Important tasks to achieve the project goals, milestones, and work packages can be provided by a WBS template (PMI 2006). Moreover, some companies have developed cost estimate templates or the so called Pro-Forma-Standard that can be used a starting point by the project team. Also in the field of risk management, some reusable templates which have reference character are used. The experience collected in this field can be documented as check lists, or risk breakdown structures (RBSs). These templates can be evaluated and updated after the end of each project.

Some researchers tried also to standardize specific construction processes that show a large scale of similarity using known BPM techniques. Hohmann (1971) made an early contribution in his doctoral thesis in this direction. He documented several technical basic models of construction processes using network models (CPM). The objective of that work was the the economization of time and effort needed for the technical preparation of construction processes. In the European ESPRIT project “CSCCM”, which aimed at optimizing the bidding process in the construction industry, a reference model as a description of an ideal bidding process was presented. The aim of this model was to assist construction companies in redesigning their bid preparation by providing them with an example of how a systematic bidding process could look like (Krömker et al. 1998). This reference model was developed using the IDEF0 modeling method. The trigger for developing this reference model was the results of the analysis of the bidding process of different construction companies. It was proved that the bidding process implemented by different companies was very much the same. Therefore, a planning effort can be reduced and an increase in the process quality can 21 STLB-Bau_dynamische Baudaten: http://www.stlb-bau-online.de/


be achieved by using such a reference model.

Other researchers preferred to generalize their contributions by developing some structural process-independent reference modeling concepts or approaches. For example, Katranuschkov et al. (2007) have suggested the Business Process Object (BPO) concept. A BPO represents a reusable process pattern with a formal definition provided by process ontology. This ontology is based on the conception of the extended Event-driven Process Chains. Each BPO is represented together with extended information about actors, resources, and services, thereby enabling true goal-driven project management and collaboration support. Several elementary BPOs can be chained together to form a more complex one. Keller (2006) suggested the term Process Pattern (German: Prozessmuster) as a general project-independent process model that can be reused in different projects. Moreover, for the management and the retrieval of process patterns he suggested storing them in a so-called Process-Repository. A complete application scenario showing how to integrate such process patterns in a cooperation construction network is illustrated in the figure 31. In this scenario four sequential phases were suggested to implement the process pattern in the whole process model, these phases are:

The selection phase, in which a suitable process pattern will be selected based on its application context and according to the information of the cooperation network and the construction process.

In the second phase, the configuration, the selected process pattern will be configured to suit the current project conditions. This is done according to some defined parame-ters. Accordingly, a process pattern variant will be derived from the configurable one.

After that, the configured process pattern will be adapted in the Customization phase. Thereby, the company-owned software will be implemented using the configured and customized process pattern.

In the usage phase, the resulted business process from the previous phases will be in-stantiated to control the corresponding local processes.

Figure 31: Application scenario for the integration of process patterns in cooperation networks, After Keller (2006)


3.9. DISCUSSION

Different BPM concepts and techniques were presented in this chapter. Some of these techniques are already used on a large scale in different industries not only to develop software tools but to document, optimize, communicate or even to simulate business processes. On the contrary, the construction sector is still not motivated to utilize such techniques to manage construction processes but still use some traditional modeling methods that have no ICT-interface in their backgrounds. Formal process modeling techniques are, however, difficult to be accepted by construction engineers, who play the role of process analysts in construction sector. This can be ascribed to its complex notation and its heavy ICT-orientation. Semi-formal process modeling techniques, such as EPC, offer a good com-promise as they play the interface role between process analysts and ICT-developers and can replace the old used modeling methods. Nevertheless, several requirements on these semi-formal techniques are still needed to be able to adequately represent the characters of the construction processes. In the following, the vision about some important requirements that should be available in a BPM technique to model construction processes is presented:

High degree of flexibility; there are main differences between construction and other sectors, such as banking or manufacturing industries. Construction is a project-based business. The degree of uncertainty faced in construction projects is higher than in other manufacturing sectors and, consequently, the risks and changes rate is higher as well. Therefore, the process models that describe the construction processes should have a certain degree of flexibility to (1) enable the representation of the exceptional process parts and to (2) permit systematic process adaptability based on the changeable conditions from case to another and even within each case.

Process standardization; although construction products carry a degree of uniqueness, they have as well general similarities. Construction processes, describing the manufacturing of these products, have also some amount of uncertainty in their flow of work. Therefore, modeling a completely constant flow for each process that will suit all instances is generally not possible. Even so, essential work steps that are needed in all the instances of a process can be specified. Thus, developing reference models to describe standard construction processes that may be needed in different projects is still feasible.

Data privacy; a construction project can be defined as a temporary alliance between different partners that have to work in collaborative way to reach the project goals. As these temporary partners can be competitors in other projects, the security of the process information on the private level must be insured. Accordingly, two levels of BPM are mainly of interest in the construction sector, i.e. the collaborative and the private level of modeling. This issue was investigated thoroughly in the research project ArKoS, which was mentioned previously in this chapter.

Level of granularity; building a process model as a hierarchy is generally reasonable as it will offer the possibility to overview, optimize, and communicate different levels of the process model by different levels of the organizational structure. Accordingly, the project manager, for example, will be interested in the process model on a level that differs from the one that a foreman will manage. Generally, it is impossible to


identify a certain degree of granularity that all construction process models have to follow. It will be advisable to leave this decision to the process analysts themselves to decide how detailed each process should be modeled. Anyhow, it is worthwhile to get use of deliverable-oriented WBS of a specific deliverable taken from different projects as a guide to develop the needed levels of the corresponding construction process. Accordingly, the lower level of the process hierarchy will be a process-oriented representation of the leaf deliverables in the WBS.

The contradiction between the first two requirements may be solved using configurable fragments within the standardized model of each construction process. This solution will ensure the needed flexibility by specifying where and how to include or exclude these confi-gurable fragments. Accordingly, a configurable reference process model can be adjustable to different project conditions. This helps to avoid starting to model each process every time from scratch. However, to realize this standardization it is anyway required from the construction institutions to structure their engineering knowledge in process-oriented way and to map it into BPM (Rüppel and Lange 2006).

C-EPC offers the possibility to model configuration aspects within an EPC model. Consequently, configurable reference business process models can be built. For the purpose of this work, normal and configurable EPC elements can be used to design the configurable fragments within a construction process model. This design will demand to establish:

Limited types of needed configurable templates for construction processes according to some possible classification.

A general structure of each type. This includes the EPC elements that constitute each template type and a method to include or exclude each type from the EPC process model.

4 . CONFIGURATION TEMPLATES FOR DYNAMIC CONSTRUCTION PROCESS MODELS 57

4. CONFIGURATION TEMPLATES FOR DYNAMIC CONSTRUCTION PROCESS MODELS

Business process models, which represent construction processes, should be flexible enough to (1) reflect the uncertain nature within these processes, (2) to enable the adaptation of these models to suit different cases or even to suit the changed conditions within the same case and (3) to react in time to exceptional situations. Business process models represent, amongst others, the time aspect of the concerned process, which is very important in construction projects. On the process level this time aspect is illustrated as chronological dependencies among the tasks. Nevertheless, this aspect can be reflected on the instance level as a process duration value. The uncertainty may lead to changes in the chronological dependencies between the tasks of a process model instance or even changes in the tasks and their durations and, consequently, this may lead to changes in the duration of the process model instance and maybe in the project duration as well. In this chapter the goals are (1) to investigate the feasibility of using the BPM technique EPC for scheduling purposes. A comparison between this technique and the aspects, needed for scheduling method, is carried out. (2) The abstraction of the process flexibility using EPC elements is also needed to model construction processes. This is suggested using configurable fragments that may be included in or excluded from the process model in a lawful way. For this reason, several configurable templates are presented as an approach to realize the flexibility in construction process models. Each of them represents one possible type of structural change within process models. These templates are classified into three groups according to the characteristics of the construction processes, described in chapter 2, and according to the aspects of BPM, presented in chapter 3. By using these configurable templates different adaptive fragments within each process model can be built to reflect the process flexibility. Normal and configur-able EPC elements are used here to illustrate the structure of the developed configurable templates.

4.1. STARTING BASIS

As it was explained in chapter 2, the high uncertainty faced in a construction project may lead to different risks and, as a result, changes may be required to the planned flow of work in the processes of the project. Consequently, a model describing such a construction process has to be dynamically changed as well. Moreover, the construction products show a considerable degree of uniqueness between different projects. Consequently, the design of a standardized construction process model that covers comprehensive process knowledge aspects and that can be used in different situations requires the ability to adjust the process model in a flexible way to the current situation. This standardized construction process includes also the proper reactions to exceptions. This means that in the current case only the relevant process fragments should be included in the model, while the other fragments have to be excluded. Such type of configuration may be needed frequently in the planning phase and even in the execution phase of the process in proactive or reactive manner.

These configurable fragments model the exceptions described in section 3.5. These exceptions can be illustrated on the conceptual level (process model) or the operational level (workflow) of a process. The interest in this chapter is to determine the possible types of construction process exceptions and how they may affect the process model (conceptual lev-el). Consequently, general exception masking or handling procedures, like Undo, Jump or

58 4 . CONFIGURATION TEMPLATES FOR DYNAMIC CONSTRUCTION PROCESS MODELS

Abort that are used to handle technical exception masking procedures are not appropriate for this purpose. Instead of that, specific configurable templates are introduced using EPC elements as a modeling solution to demonstrate the exceptions of construction process.

A construction process model represents the process knowledge described as a chronological dateless sequence of the tasks needed to fulfill the process objectives. An instance of this process model can be provided by start and end dates for its tasks. Therefore, the process model instance should be able to play the role of a process schedule in its current implementation. Consequently, the changes done to the process model or to its instance as response to some exceptions will be accompanied also by change in the duration of the current process model instance. For that reason, it is also essential to check the ability to use process model instances as process schedules. This will be done by trying to reflect the main features of traditional scheduling methods using EPC technique.

Actually, EPC was not arbitrary chosen to represent the developed configurable templates. EPC is an event-driven method used to model business processes. This makes it suitable to represent exceptions as “deviation or problem” events in the process model and to show the actions as a response tasks to the deviation events. Moreover, EPC supports configurable modeling as it has some specification to represent configurable elements within the developed process model. Configurable modeling can be beneficially applied to model construction processes. As uncertain events may occur and may not, it will be wrong and will not reflect appropriately the reality of a construction process to model such events as normal elements.

4.2. THE ABILITY OF BPM TO REFLECT SCHEDULING FEATURES

A process model abstracts a process in several steps that are connected to each other chronologically and logically. An instance of this process model will be provided by all the current process instance data. In the construction sector, the time needed to execute each of the process steps is a very important contractual factor and it can influence or be influenced by many factors such as cost, resources, procurement etc. By providing a process model instance with task dates (start and end dates) it should be possible to use this instance as a process schedule for the specific case at hand. Consequently, a project schedule can be theoretically generated from the process schedules if a clear process interdependency plan is available in the project. For that reason, the feasibility of using different important scheduling aspects in BPM will be checked in the following.

4.2.1. PRECEDENCE RELATIONSHIPS IN A BUSINESS PROCESS MODEL

In project management several types of precedence relationships between the tasks can be found in schedule networks. The most common and easiest type is the end-to-start relationship. Other types like start-to-end, end-to-end, or start-to-start can also be used in schedule networks. These relationships will be even more complicated if a task is associated with a lag or a lead value. The only type of these relationships that is represented explicitly in business process models is the end-to-start relationship without lead or lag. Other types of relationships can be only implicitly modeled. In the following, all these kinds of relationships will be represented using the EPC technique. Start-to-end, end-to-end, and start-to-start relationships have the implication that the related tasks will be executed in a partially interleaved time. Therefore, such relationships can be represented as if both tasks will be executed in parallel to each other. Accordingly, it is assumed here that the parallel split in EPC means that the tasks will start concurrently, if all the needed resources are available, and each one will finish according to its needed execution duration. The following task after the parallel merge will not start until both parallel tasks have been executed. Stop task is presented, according to the work of Klauer (2005), to develop the needed lag in the


concurrency between the parallel tasks. This stop task is an automatic one that will be executed by the WFMS or a connected application without a need of any user intervention. It has no resources and helps only to stop the execution on its path for a time equal to its duration. The duration of this Stop task is decided according to the relationship type, lag or lead value, and tasks durations. The EPC based patterns in figure 32 are suggested to cover all types of relationships that can be faced in schedule networks and they are compared to their equivalent Gantt chart patterns. It is remarkable that even the events are excluded from these EPC patterns in this figure for simplicity but their graphical representation is still complex.

Start‐to‐start

End‐to‐end

Start‐to‐end

End‐to‐start

Figure 32: The templates of the precedence relationships in EPC process model (adapted from Klauer 2005)


4.2.2. COMPARISON BETWEEN NETWORK SCHEDULING METHODS AND EPCS

As we showed that it is feasible to represent all types of precedence relationships using EPC as an example of BPM techniques, a comparison between an instance of a EPCs model and a common network scheduling method, the critical path method CPM, will be shown below with the goal of checking the ability to use EPC model instance as a process schedule network. CPM is merely a graph, which consists of vertices and edges. The vertices represent the work steps, i.e. the tasks, weighted with task durations. The edges represent the start and end events connecting tasks. In some references the tasks are represented in CPM as edges and the relationships as the vertices connecting tasks. CPM serves to calculate the critical path and the float for all tasks in the network. Anyhow, the mathematics-based algorithm of the CPM will not be discussed in this work. This comparison is made using a ready CPM example presented by Uher (2003) as it is shown in the upper part of the figure 33. In the lower part of the same figure an EPC model represents the same schedule network is introduced and the same common CPM forth and back calculations are done to determine the critical path and the other CPM values. By comparing the elements of the CPM model with the EPCs model’s elements, it is clear that the later has additional elements. These elements are (1) the functions, which are the tasks22 within the CPM diagram that are shown as the vertices connecting the events, also (2) AND connectors. This all makes the EPC diagram graphically more complex than the CPM diagram in representing this simple example. Never-theless, the EPC method has more advantages than traditional modeling or scheduling me-thods used in project management, such as CPM method, due to the conformance to ICT re-quirements and databases. Moreover, EPC model can specifically be enhanced using extended EPC elements to include the resource limitations and the involved organizational units in each task (Scheer 2000). Dummy tasks, which are needed to show complex task dependencies, are shown in CPM in figure 33 as dashed vertices connecting events (2, 3, and 4). In the EPC model the same dummy tasks are represented using the arrows that are connecting the connec-tors to each other. Consequently, it can be interpreted from the EPC model that such a dummy task is a resource-free zero-duration one. As a result, it can be generally said that it is applica-ble to use BPM techniques (EPC instance as an example) as a precedence diagram method to schedule the tasks in a process plan.

Figure 33: A comparison example between EPC and CPM

22 The terms Function from BPM domain and Task from project management domain are used here as synonyms


4.2.3. DETERMINISTIC PERSPECTIVE OF A PROCESS MODEL

A business process model is designed according to the control flow schema. This means that the modeler has to decide the temporal and logical interrelationships between the tasks in the process model (sequence, parallel), i.e. what are the successors and the predecessors of each task in the process. Actually, the same way is used in project management to decide the inter-relationships in the typical network planning methods. However, in the practice of construction project management, deterministic schedule plans are used to control the progress of construction processes. On the contrary, it is common in BPM to have alternative paths (using XOR connectors). To implement and use such a business process model as a part of a schedule plan, a deterministic instantiation of the process model is needed. This can be done by separating the process model to all the alternative models that do not include any XOR connectors, i.e. deterministic models. After that, the alternatives should be evaluated based on some criteria, e.g., time, cost, error rate etc, to choose the most suitable one to the current project conditions (see figure 34). In the case that the conditions, upon which the first alternative was chosen, have been changed, then this alternative may be replaced by another one, which is more suitable to the new conditions.

Figure 34: The separation of an EPC process model to its deterministic alternative models

4.3. SUGGESTED CONFIGURATION TEMPLATES FOR EXCEPTION HANDLING IN CONSTRUCTION PROCESSES

A main hypothesis of this work is that all possible ways of changes in the structure of construction process models, as a response to probable or even actual risks, can be standardized by generalized templates. A risk treatment or an exception handling in the process model will follow one or more of these templates to deal with an unexpected situation.

For this purpose, in the following several templates will be suggested as types of configurable fragments within process models. Those are assumed to cover all kinds of construction process model related structure changes and consequently they will offer the needed flexibili-ty in the process model. In view of that, a configuration template can be defined as a basic type of configurable fragments in the process model that describes one possible way of model


structure change as a response to a certain event. As a result, a configured and specified tem-plate can be used to represent an actual or a virtual structural change in a process model caused by the response to a specific risk event. Nevertheless, more than one configuration template may be used to represent a complex effect of one risk as changes in more than one location in the process model. In this sense, dealing with complex issues does not require complex templates as the basic suggested templates can be used together to cover the change case. This equates to dealing with a big problem not as a whole but by simplifying it into several parts and dealing with each one separately.

Building upon the classifications of risks and changes in the literature of construction management two major aspects were considered important from the process-oriented perspective. These aspects are (1) the timing of response to the exceptional event (proactive or reactive response) and (2) the effect of the exceptional event on the progress of the process, i.e. will it cause progress interruption or not. In view of that, the templates are classified into three main groups. These groups are:

General Templates; can be used in the case when changes are needed in the process before the affected task is started, as well as, they can be used as a response to an event that has already occurred. Accordingly, these templates can be implemented in either proactive or reactive treatment cases. Because of that, this group of templates is entitled as general templates group.

Interruptive Templates; used to describe a change that affects and stops a task during its execution.

Reactive Templates; used as response to events which have affected tasks or products considered to be completed.

4.3.1. GENERAL TEMPLATES

The general templates group contains the following configurable templates

Insertion template

Substitution template

Cancelation template

Parallelism template

These templates are described in details in the following:

INSERTION TEMPLATE

This template represents a case, in which a new task will be inserted in the process model (1) after a certain planned task or (2) before it or even (3) between two planned tasks. Semi formally, it is described in the figure 35 using the EPC elements as a configurable fragment of an EPC process model. This fragment is located between two configurable XOR connectors and contains the new task T(m) that may be inserted in the process model. The configuration freedom of the C-XOR connectors is constrained using two requirements. The first one controls the consistency between the branch and the merge C-XOR connectors, i.e. the EPC model correctness after configuration. This means that both C-XOR connectors will be configured to the same element type. The second requirement shows under which condi-tions each configuration variants will be adopted. It is written as If-Then statement that


controls the right path choice according to the Risk (ON, OFF) cases. Accordingly, the confi-gurable fragment will be mapped to a sequence of events and tasks that includes T(m) when relevant information will be received, i.e. Risk = ON case (see configured case 2, figure 35). In the case that this risk is not expected to occur, i.e. its probability/impact is below the thre-sholds the T(m) path will be skipped, i.e. Risk = OFF case (see configured case 1, figure 35). Therefore, the configurable fragment will be mapped to a sequence of events and tasks, which will not include T(m). This is the normal situation when the planned process model will be executed without any change. The meaning of “Risk = ON” is different from the proactive and reactive management points of view. In the proactive one it means that the deviation event did not occur yet but has a considerable probability/impact on the targeted tasks accord-ing to the agreed tolerance thresholds. Consequently, the new task T(m) is approved as “needed” by the responsible team. In the reactive one it means that the deviation event has occurred and it needs T(m) as a part of the response to the actual problem. The risk status (ON/OFF) will be decided according to external information, received by a preceding task. Such type of information may be traced by an observation or monitoring process that is carried out in parallel to the considered process (Faschingbauer 2010).

The new inserted task in the figure 34 is expressed here in general as one task named “T(m)”. However, this task can be refined to acceptable level of detail using the hierarchical EPCs concept.

Configurable template Configured case 1 Configured case 2

Figure 35: Insertion template (left) and its two configuration cases (right)


SUBSTITUTION TEMPLATE

This template represents the case, in which a new task will substitute a planned one or a

planned chain of tasks. This case is described semi formally in a template using EPC

elements (figure 36). The configurable fragment in this template is contained between two

C-XOR connectors. This fragment includes task T(m) that will substitute task T(j) in the

planned process model if some conditions will change. The configuration freedom of the

C-XOR connectors is constrained using two requirements. The first one will ensure the

correctness of the EPCs model after configuration. The second one is shown as If-Then state-

ment that will control the choice of the right task (j or m) according to the available informa-

tion. T(m) can be understood as an alternative one to T(j) but it was not adopted in the

planned case because of, e.g., its higher cost, its longer duration, or maybe because it is tech-

nically more complicated to be executed.

Risk = ON case in figure 36 means that the new task T(m) will be chosen to substitute

task T(j), while Risk = OFF case means that the task T(j) will be executed without any

change to the planned process model.

More complicated cases can be faced if the task T(m) will substitute several tasks in the

process model. Such a case will be discussed later in this work (see 4.4).


Risk=ON

C-XOR = SEQ(T(m))

T (m)

T(m) is done

T(i)

T(k)

T(k) is done

Change approved

External information/

change relatedInput

Figure 36: Substitution template (left) and its two configuration cases (right)


The substitution case can be faced in construction processes, for example, in the following

circumstances:

Assume that an identified risk is considered not a threat to the project objectives,

because the assessment results showed that its danger is below the agreed thresholds.

After the construction started, in the post-fixity phase, and according to more reliable

information, the risk has been found to be more dangerous than what was expected. As

a countermeasure, certain tasks may need to be substituted with other tasks, which are

more suited to the new situation.

It can also be the case when a new risk, which was not identified before, appears.

According to the study of the characteristics of this risk it was found that the

substitution of some tasks with more suitable tasks will be the best solution to

mitigate or avoid or even eliminate its threat.

This case can represent also a change in the owner preferences. The owner may prefer

to replace a product partly or even completely with other one, which satisfies more his

expectations. Replacing the product will need the substitution of the related planned

tasks with new tasks to produce the new aimed deliverables.

CANCELATION TEMPLATE

The cancelation template represents the case, in which a planned task will be canceled from the process. This case is semi formally described in one configurable fragment using EPC elements (figure 37). The fragment contains, as in the previous templates, two parts (normal and configurable parts). The configurable part is contained between two C-XOR (branch-merge) connectors. Two paths are contained in between these two C-XOR connectors. On the first path there is the task to be canceled (Task T(j)). On the second path there is no task, i.e. an empty path. By canceling one of the planned tasks, the resources that were assigned to this task will be free and can be assigned to other tasks that are in need for them.

This case can be faced in construction processes, for example, in the following circumstances:

In the post-fixity case, it is possible to cancel some planned tasks when an unlikely threat becomes highly expected. Consequently, some changes must be done as a proactive response to the coming danger by canceling some planned tasks and adding other new tasks somewhere else in the process model. Thus, the cancelation template will play a supplementary role to the insertion or substitution to achieve the needed process changes.

It can be used if some tasks are planned to handle an expected threat. After the execution started more reliable information was obtained that this threat is not expected any more. Hence, the planned countermeasures should be canceled.

The changes in the owner’s objectives may lead to go no further in producing one or more of the planned elements. Therefore, their production tasks should be canceled from the process plan.

The configured case 1 in figure 37 shows that no changes will occur to the planned process. On the contrary, case 2 shows the case where the planned task T(j) will be canceled from the


process model. This comes in conformance with the Risk status (Off, ON) respectively. In the configured case 2 in figure 37 it is assumed that Task T(i) will be connected to task T(k) in a predecessor-successor-relationship after the cancelation of the Task T(j) .


R(1)Branch C-XOR = Merge C-XOR caseR(2)If Risk=ON then C-XOR=SEQ((Change approved)Event) else C-XOR=SEQ(T(j))

T(j)

T(i)is done

T(i)

T(k)

T(k)is done

T(j)is done

Change approved

XOR

XOR

REQ

R(1)R(2)

External information/

change relatedInput

Figure 37: Cancelation template (left) and its two possible configured cases (right)

PARALLELISM TEMPLATE

This template represents a case, in which a new task will be inserted to the planned process model. This insertion will be not after a planned task or between two planned tasks in the process model but in parallel to planned task(s). This case is described semi formally as a configurable fragment in the template as illustrated in figure 38.

In this template the configurable fragment is contained between two C-OR connectors (branch, merge) and not C-XOR as in the previous templates. Since in EPCs the parallelism is modeled using the AND connectors, it was needed to use a configurable connector that can be configured to an AND connector. As it was shown previously in table 3, this is possible in the configuration constraints of the C-OR connector.

The configurable part contains two branches, a planned main one within the essential process model and an exceptional one that can be added, under special circumstances, in parallel to the first branch.

The template introduces task T(m) as the new one that can be added in parallel to the planned task T(j). If needed, task T(m) can be represented as a hierarchical one that has different levels of detail.

To limit the configuration freedom of the C-OR connector, a conditional If-Then expression is


used as a requirement. Accordingly, two cases are only possible:

AND in case of parallelism, i.e. when Risk = ON,

Normal sequence contains only the task T(j) when Risk= OFF.


Figure 38: Parallelism template (left) and its two possible configured cases (right)

This configuration case can be faced, for example, in construction processes where it is needed to avoid running over the agreed upon schedule. Therefore, parallel execution will save some execution time. This new parallel task can be a treatment action needed to handle an anticipated or actual risk. Or it can be a result of a change order caused by a new external facultative or imposed situation or a result of an alteration in the owner objectives.

4.3.2. INTERRUPTIVE TEMPLATES

Interruption occurs when some event interrupts and stops temporarily the execution of a task in the business process model (see disturbance risk in 2.5.4). Generally, this interruptive event is unexpected and, therefore, unprepared against in proactive way, e.g., (1) a very bad weather will interrupt the execution of outdoor construction tasks or (2) a supply delay will interrupt the execution of the tasks that are in need for some resources, or even (3) a human error that may happen suddenly during the execution of a task may cause such an interruption.

The interruption concept in a construction process model, adopted in this work, is explained in figure 39. Assume that task B is interrupted by a disturbance risk event. The interrupted task can be refined, as a hierarchical task, to some atomic tasks. Consequently, the interrup-tion may be assumed to occur between two atomic tasks and not through any one of them. All the atomic tasks, before the interruption point, can be merged in one “pre-risk” sub-task. As


well, the atomic tasks, after the interruption point, can be merged in one “post-risk” sub-task. The risk event and the following treatment action will be located between the pre- and post-risk sub-tasks. This interruption concept presented here assumes that the interrupted task can be detailed in more than one level of granularity. Otherwise, the interruption will demand to re-do the interrupted task completely from the beginning.

Figure 39: The Interpretation of a task interruption in an EPC model.

Based on figure 39 and on the risk and change management standards discussed in chapter 2, an interruptive template should contain four additional elements:

Interruptive event; represents the cause of interruption in the modeled case. It shows that the planned task will not be followed in the current instance by its finishing indicator event as in normal cases, but it will be followed by an unexpected and therefore unplanned event.

Preparation task (P); as it is impossible to start any action immediately after the interruption has occurred, because some intermediate measures may be needed, such as problem analysis, treatment planning, owner approval, and decision making. Therefore, a preparation task is needed, before starting the treatment measures, to han-dle the interruptive event. The needed preparation measures may differ from one case to another according to different factors, e.g. staff experience, project type and risk characteristics.

Treatment task (T); the details of this task are determined in the preparation task. Resuming task; as the task is interrupted, it will be stopped temporarily. Then, after

the risk is treated this task needs to be resumed. The resuming appears as a task called “Task Resuming”, which will be located directly before the finishing indicator event of the whole task.

The interruption will extend the task’s duration and can delay the whole process if the task is on one of the process critical paths, or if its path has a float smaller than the occurred delay, so the process critical path will change. Therefore, it is reasonable, if applicable, to increase the resources in the resuming task, which means to reallocate resources between the affected and the non-affected tasks to try to compensate the wasted time because of the interruption. Of course, a balance must be made between the increased cost and the wasted time to choose the best solution for the current situation. Anyhow, the consideration of the resources and costs within the process model is not within the focus of this work.

In the developed interruptive templates, which will be presented later in this chapter, the pre-risk task will have the name of the interrupted task and the post-risk task will be represented as “Resuming” task.


INTERRUPTIVE TEMPLATE (ACTION CASE)

In general it can be said that if a task will be disturbed by an undesired event, some actions will be needed to eliminate the disturbance, and to enable the continuation of the planned task(s). According to 2.5.4 this disturbance can be:

A negative event which was not expected and, therefore, not prepared against before. A risk event that was identified but thought to have probability/impact values within

the accepted thresholds. Therefore, the prepared measures, if any, against this event are not appropriate to its intensity.

A negative event, which is impossible to be predicted, e.g., human errors or acts of God.

The action case of the interruptive template is shown semi formally in figure 40. It includes, like the other previous templates, a configurable fragment that is here contained within two C-XOR (branch, merge) connectors. Accordingly, the template has two configured cases. The first case shows simply a sequence from the task T(i) to its finishing indicator event “T(i) is done”. This means that the task T(i) will be executed normally without any disturbance. The second one is to be followed when a disturbance will occur. This contains the disturbance Risk(n), the task “Action preparation”, the treatment action T(n), and the resuming task of the task (i). Each one of the tasks (action preparation, disturbance treatment) can be theoretically mapped to a subordinated EPC model, describing the details of each task, i.e. as a hierarchical task.


Figure 40: Interruptive Action template (left) and its two possible configured cases (right)


Some hierarchical relationships (parent/child) need to be established or modified through the configuration. The date of occurrence of the disturbance will decide which sub-tasks will be added as child list of the Task T(i) Resuming and in the same time will be removed from the child list of the task T(i). According to the assumption shown in figure 39, a disturbance occurs between two atomic tasks and not through any one of them in the hierarchy. Therefore, all the subtasks that have start dates later than the disturbance start date will be included with-in the resuming task.

INTERRUPTIVE TEMPLATE (STOP CASE)

The stop case is a special case of the Interruptive Action template. It shows the negative reaction to an event that has interrupted the execution of a planned task. In some cases it is impossible to do anything against the disturbing event, e.g. unexpected very bad weather will inevitably stop the work in the planned outdoor tasks until the weather conditions become well. Consequently, the interrupted task will be stopped until the effect of the disturbing event is finished. This case is modeled in a template as shown in figure 41. In this template, if the task T(i) will be interrupted by an event (Risk (1n)) then the remaining part to be executed will be represented in the task (T(i) resuming). The task (Stop) appears between task T(i) and its resuming part has no resources and helps only to stop the execution on the path where it is located for a time equal to its duration, see the Stop task concept in 4.2.1. The duration of this Stop task is determined according to the start date of the disturbance and the date of starting the resumption task. The configured case (1) in figure 41 represents the optimal situation, when the task will not be disturbed by any interruptive event. Otherwise, the situation will be represented using the configured case (2).


Figure 41: Stop template (left) and its possible configured cases (right)


4.3.3. REACTIVE TEMPLATES

Reactive treatment is used as a response to events, which have already occurred. Although, the same suggested templates in the general treatment group can be as well used for the reactive treatment, new templates are suggested in this group to cover other aspects needed in the reactive treatment to handle some construction process cases.

The product of a construction process can be tangible or intangible one. Bidding documents, cost estimate, or bill of quantity are examples of construction intangible products. Founda-tions, walls, roofs and columns are examples of construction tangible products, i.e. the products that have physical manifestation. The combination of tangible and intangible delive-rables from several processes forms the product(s) of a construction project. Each one of these deliverables passes through several statuses until it reaches its final status at the planned end. If a relevant unexpected event will arise within the process time, it may affect the deliverable, which is still in development. This event may affect the status of the deliverable, i.e. it may be needed to repeat one or more of the already done steps to remedy the affected status(es) of the deliverable. Nevertheless, the affected deliverable of a construction process that has a tangible product may need to be replaced by another one, i.e. it will be needed to demolish several statuses of the deliverable or even the whole deliverable and, afterwards, to repeat the same steps again. Based upon this, two extra change templates are suggested in the reactive group, namely the Repetition and the Demolition templates. These reactive templates presented here are only applicable on the instance level and their cases cannot be documented on the refer-ence level of the process.

REPETITION TEMPLATE

Due to different reasons like the deficiency of the product quality, changes of the perspectives, or human errors, it may be required to repeat the task(s) that lead to a specific product, i.e. task rework (see 2.6.3). This rework case is described using EPCs elements in a template named repetition template (see figure 42). The repetition appears only on the instance level and should not be documented on the process model level as it will not enhance the included process knowledge in the model. The repetition template was previously introduced, in the workflow literature on exception handling as a Redo loop which can be used to model the re-execution of a task until its planned result will be reached, see (Luo et al. 2000; Rüppel and Klauer 2004). However, this Redo loop assumes that the repetition will be done directly after the first execution trail. Nevertheless, discovering the need of repetition in construction processes is mostly not immediate. In other words, late detection of the defects is highly possible. This can be known only after uncertain period of time following the task’s first execution, or even after the end of the whole process. Note that the configurable fragment of the Repetition template presented on figure 42 will not necessarily appear in process sche-dule plan directly after the first task execution. Therefore, the repetition template is more suit-able than the Redo loop for the construction processes. The repeated tasks will need usually the same originally assigned resource and personnel as in its first implementation.



Figure 42: Repetition template (left) and its two possible configured cases (right)

DEMOLITION TEMPLATE

Demolition describes a case that may happen in construction processes only with tangible products. As an example of this case, assume that the contractor has found according to some field tests that the in-situ concrete columns do not achieve the required strength. This can happen due to many reasons, e.g. a low quality of cement was used, or bad care while and after concrete pouring in a freezing weather. Therefore, the weak-strength columns must be removed. The column concrete work has to be repeated later, i.e. reinforcement preparation, framework assembling, concrete placement, framework dismantling, and aftercare. Another example of a demolition case can be encountered if the owner has just changed his preferences and wanted a new product instead of an already built one. This may demand to demolish the already built product without a need to repeat its production tasks.

The demolition case can be represented using EPC elements as a symbolic template. It includes new elements which represent the inputs and outputs of each task. Each input and output is shown using a rectangle with the product name and a status. The status describes the actual phase of the product assuming that each product will pass through several phases with-in the process until it will reach the final planned status. As it is shown in figure 43, the product (x) that has the status (n-1) is the input to the Task T(i). As a result from this task, the same product (x) is the output but with the status (n), i.e. through the task T(i) the status of the product (x) has changed from (n-1) to (n). The task T(m) will demolish the work done in the task T(i). Consequently, it will get the product (x) with the status (n) as an input and will produce the product (x) with the status (n-1) as an output. The presented template showed just the case of changing the status of the product. It can also be needed to demolish not only one status but an entire product of the process. The content of the demolition task, T(m), in the template is dependent on the affected product and needs generally different


resources from the resources of the Task T(i) that is used to produce the demolished product. Demolition details can be documented as a part of the process knowledge but in fact it is dealt with in the practice always in ad hoc way, as nobody will anticipate demolition in the planning phase as a part of a construction process.

The demolition, like the repetition case, may take place after the whole process will be theoretically finished and not immediately after the execution of the planned task.


R(1)Branch C-XOR = Merge C-XOR R(2)If Risk=ONthenC-XOR=SEQ „T(m)“else C-XOR= SEQ (T(j))

T (m)„Demolich product (x), Status (n)

T(i) is done

T(i)

Risk/Change

approvedREQ

R(1)R(2)

XOR

XOR

Product (x)Status (n-1)

Product (x)Status (n)

Product (x)Status (n-1)

Input

Output

Input

Output

Figure 43: Demolition template (left) and its possible configured cases (right)

4.3.4. FORMAL REPRESENTATION OF THE CONFIGURATION TEMPLATES

For a formal and generalized representation of the configuration templates, a logical descrip-tion is carried out that illustrates the changes between the configured case 1 and 2 of each configuration template23. This is done by considering the process model as a directed graph without multiple edges (Jungnickel 2008). This graph consists of vertices (represent the tasks) and relations (represent the control flow). For the notation of this formal description the symbols in table 4 are used.

This formal description is limited to the general configuration templates (4.3.1) because:

The interruptive templates (4.3.2) have similar description to the Insertion Template. However, the insertion of the treatment actions will be carried out in a lower level of the process model hierarchy.

The reactive templates (4.3.3) will be carried out using one of the general configura-tion templates (Insertion, Parallelism). For example, the repetition of a planned task may be planned between or in parallel to already planned tasks.

23 For linear sequential process models, as shown graphically in the configuration templates, these changes can be described and carried out using convenient Linked List algorithms.


symbol use

is a subset of

is a proper subset of

is not a subset of

Conjunction (and)

Disjunction (or)

Negation (not)

→ implication

↔ equivalence

is an element of

universal quantification

existential quantification

A \ B All elements in A but not in B

Intersection

Union

A Set A

a Element a

n(A) The numbers of elements in A

Empty set

Table 4: The used notation for the formal description of the configuration templates

DEFINITION OF THE PROCESS MODEL GRAPH

Let : , , ,G T R be a process graph with a set of tasks T and a set of relations R, i.e.:

: 1T t tn

: , ,,R r r t t t t Tt t i j i ji j

Tasks are connected to each other through relations. A relation connects a start task and an end task together, i.e.:

: | ,R T r tt t ii j

: | ,R T r tt t ji j

For each task a set of outgoing relations B+ as well as a set of the incoming relations B are

defined:

: :B t r R r ti i

: :B t r R r ti i


The set of the successor tasks S of and the set of the predecessor tasks P of a task it are

defined as follows:

: : | ,S t t T r R r t r ti j i j

: : | ,P t t T r R r t r ti j j i

If a task has zero predecessors, then it is a start task ts in the process graph. In the same way if

a task has zero successors, then this task is an end task te in the process model graph.

: , :

: , :

t t T B ts i i

t t T B te i i

For the following graph configuration it can be defined that the relation ,rti tj belongs to the

set of the outgoing relations B ti

of the task ti . As well as, the relation ,rti tj belongs to

the set of the incoming relations B t j

of the task t j . In other words, this means that ti is a

predecessor of t j and t j is a successor of ti .

,r B tti tj i

,r B tti tj j

t S tj i

t P ti j

A path in the graph can be defined as a sequence of tasks from T, where no task is repeated and there is a relation between each pair of tasks in the sequence Pathk.

1: ,...,Path t t Tnk

,t t Path i j t ti j i jk

1,..., 1, 1r R i nt ti i

INSERTION TEMPLATE - FORMAL DESCRIPTION

The insertion on of a new task (figure 35) can be before or after at least one existing task in the process model, or between exactly two existing tasks in the process model.

Prior to the insertion of a new task before or after a set of existing tasks it should be proofed that there are no two existing tasks from this set that belong to the same path. In other words a sub set A of the existing tasks set T with more than one element should not be a sub set of a Pathi in the graph.


1( ) 1 ( ) 1 | 1,...,n A n A t A t Path i nj j i

The insertion of a new task (m), after a set of afore tasks A T , means that the new task (m)

will be added to the tasks set T. Moreover, by the insertion of the new task (m) after A the relations between the tasks in the process graph should be adjusted. The relations between all

the tasks from the set A and their successor tasks S t t Ai i should be deleted and new

relations should be added to the set R. In the same way the set of the outgoing relations

B ti

and the incoming relations B ti

as well as the sets of the successors S and prede-

cessors P should be adjusted as well. The changes in the process graph sets that accompany the insertion of the new task (m) after A in the process graph are described in the following:

: { }T T m

|

: \ , , ,

: \ , ,

: ,

: ,

: \ , ,

t Ai

t t S tj j i

R R r r rti tj ti m m tj

B t B t r ri i ti tj ti m

B m rm tj

B m rti m

B t B t r rj j ti tj m tj

: \

:

:

: \

S t S t t mi i j

S m t j

P m ti

P t P t t mj j i

The insertion of a task before set of existing tasks can be represented using similar description for the last one.

The insertion of a task between exactly two existing tasks ti and tj will demand to proof that these two tasks are adjacent tasks in the process model graph, i.e.:

1 :,r R t T t Tti tj i j

The changes in the process graph sets that accompany the insertion of the new task (m) between exactly two existing tasks ti and tj in the process graph are described in the following:


: { }

: \ , , ,

: \ , ,

: ,

: ,

: \ , ,

: \

:

:

: \

T T m

R R r r rti tj ti m m tj

B t B t r ri i ti tj ti m

B m rm tj

B m rti m

B t B t r rj j ti tj m tj

S t S t t mi i j

S m t j

P m ti

P t P t t mj j i

SUBSTITUTION TEMPLATE - FORMAL DESCRIPTION

A new task may substitute an existing task (figure 36) or a sequence of existing tasks in the process model. In the second case it should be proofed that the substituted tasks form a sequence in the process model. In other words, the substituted tasks should be a sub path of a path in the process graph. This sub path is located between two defined tasks Tbegin and Tend and described as follows:

: { ,..., }SubPath t t Pathik begin end

The substitution of a task is a special case from the substitution of a SubPathkin the process

graph. So only the predecessors of the Tbegin will be inherited by the new task (m) as predeces-sors. The successors of Tend will be inherited as successors of the new task (m). After that the whole SubPathk

tasks and their connections in R, B+ and Bwill be deleted. As well as, new

relations between the task (m) from one side and Ti, Tj from other side will be created.

The changes in the process graph sets that accompany the substitution of SubPathkwith task

(m) in the process graph are described in the following:

|

|

: \ , ,

: \ , ,

t t S tk k end

t t P ti i begin

R R r rti t ti mbegin

R R r rt tk m tkend

: { }T T m


: ,

:,

: ,

: ,

B t B t ri i ti m

B m rm tk

B m rti m

B t B t rk k m tk

: \

:

S t S t t mi i begin

S m tk

:

: \

P m ti

P t P t t mk k end

: { ,..., }1|

: \{ } {1,..., 1}, 1|

: \ 1,..., , , ,

: \ 1,..., , , ,: \{ }

SubPath t t Pathnk ft t SubPathi i k

R R r i nti tit t Tz z

B t B t r i n r Ri i ti tz ti tz

B t B t r i n r Ri i tz ti tz tiT T ti

CANCELATION TEMPLATE - FORMAL DESCRIPTION

The cancelation of the task Tj from the process model graph (figure 37) means that this task and all the relations that contain this task will be deleted from the related sets of the process model graph. A general case can be presented when a SubPathk

from the process model graph

will be deleted. So only the predecessors of the Tbegin in SubPathkwill be linked to the

successors of the Tend in the SubPathk. After that the whole SubPathk

sets will be deleted from

the process model graph.

The changes in the process graph sets that accompany the cancelation of SubPathkfrom the

process model graph are described in the following:

|

|

t t S tk k end

t t P ti i begin


: \ ,

: \,

: { },

: ,

: ,

R R rti tbegin

R R rt tkend

R R rti tk

B t B t ri i ti tk

B t B t rk k ti tk

: \

: \

S t S t t ti i begin k

P t P t t tik k end

: { ,..., }1|

: \{ } {1,..., 1}, 1|

: \ 1,..., , , ,

: \ 1,..., , , ,

: \{ }

SubPath t t Pathnk ft t SubPathi i k

R R r i nti tit t Tz z

B t B t r i n r Ri i ti tz ti tz

B t B t r i n r Ri i tz ti tz ti

T T ti

PARALLELISM TEMPLATE - FORMAL DESCRIPTION

A new task may by inserted in parallel to an existing task (figure 38) or a sequence of existing tasks in the process model.

A general case can be presented when a new task (m) will be inserted in parallel to a

SubPathk. So only the predecessors of the new task (m) will be the predecessors of Tbegin in

SubPathkand the successors of the new task (m) will be the successors of Tend in SubPathk

.

Here, no elements should be deleted from the sets of the process model graph.

The changes in the process graph sets that accompany the parallelism of SubPathkfrom the

process graph are described in the following:

: { }T T m


|

|

: ,

:,

t t S tk k end

t t P ti i begin

R R rti m

R R rm tk

: ,

:,

: ,

: ,

B t B t ri i ti m

B m rm tk

B m rti m

B t B t rk k m tk

:

:

S t S t mi i

S m tk

:

:

P m ti

P t P t mk k

4.4. USING CONFIGURABLE FRAGMENTS IN PROCESS MODELS

A configurable fragment is an implemented instance of one of the configuration templates in a

process model. In this work, a configurable process model is defined as a process model that

contains one or more configurable fragments. Figure 44 shows a configurable process model

that contains three configurable fragments, namely (I) insertion of T(r) after T(i), (II) T(y)

parallelism to T(k) as well as (III) T(m) and T(n) substitution by T(s). The configuration

requirement R(1) links the configurable fragments (I) and (II) together. So according to the

Risk 1 status (ON, OFF) these two configurable fragments will be configured. The link of

configurable fragments through the requirements builds a way to reflect the case when a risk

may cause changes in different positions in the process model.

The configurable fragment (III) in figure 44 is configured according to the (ON, OFF) status

of Risk 2. Accordingly four Configured Cases (CCs) can be derived from the configurable

process model in figure 44. Theses CCs are:

CC 1 when Risk 1 = OFF, Risk 2 = OFF

CC 2 when Risk 1 = ON, Risk 2 = ON

CC 3 when Risk 1 = OFF, Risk 2 = ON

CC 4 when Risk 1 = ON, Risk 2 = OFF


Configurable process model CC 1

R(1)

If Risk 1 = ON

Then

C-XOR (1)= SEQ(T(r))

and

C-OR (3)= AND

else

C-XOR (1)= SEQ(T(j))

and

C-OR (3)= SEQ(T(k))

R(2)

C-XOR (1)= C-XOR (2)

R(3)

C-OR (3)= C-OR (4)

R(4)

If Risk 2 = ON

Then

C-XOR (5)= SEQ(T(s))

else

C-XOR (5)= SEQ(T(s))

R(5)

C-XOR (5)= C-XOR (6)

CC 2 CC 3 CC 4

Figure 44: A configurable process model and the four possible configured process models derived from it.


4.6. ALTERNATIVES ANALYSIS

In all the suggested templates, there was only one solution (expressed as a task) to solve the supposed exceptional case. Generally, more than one solution can be available, e.g. based on experience, company knowledge etc, for the special problem at hand. These alternatives may even not follow the same configuration template to be integrated in the process model. The main point here is how or according to which criteria one of these alternatives has to be cho-sen as the adopted solution. Basically, time or cost aspects, or both of them are the most con-sidered parameters in such cases to make the choice among the alternatives. These aspects may not be sufficient to make the decision of the most suitable alternative, as other aspects may be as important as the time and cost attributes for the decision maker. The experience in performing the method, the needed resources and technical requirements, and the risk rate accompanying adopting each solution can be important parameters that will influence together the decision making results.

Multi-Criteria Decision Analysis (MCDA) aims to define a preferred alternative, to rank the alternatives in a subjective order of preference according to different criteria. MCDA includes several methods, which can be used to help the decision makers to find the solution that best suits their problems, such as:

The Simple Multi-Attribute Rating Technique (SMART)

The Analytic Hierarchy Process (AHP)

An example is illustrated in figure 45 to show how to add a weight to two alternative tasks in the substitution template using the AHP method. Each one of the alternatives can be used in-stead of the task T(j) in case that a specific exception will occur. A pairwise comparison is made between two available alternatives, task T(k) and task T(m) according to four criteria (time, cost, risk rate, and technical complexity). In this example, it is assumed that the time is the most critical factor, followed by the cost then the complexity and finally the risk rate. The decision maker can use concrete data, like the estimated cost of each task, or the judgment about the relative importance of the studied element, like the case of high or middle technical complexity, associated with the task execution. The priority of each alternative indicates the weight in reaching the goal of the process. It is shown as an absolute number between (0-1) and confirms here that the task T(m) is more desired than the task T(k) as it has the biggest weight (0.542), see figure 45. The AHP calculations24 needed to reach this result are not detailed as this is not within the scope of this work. For more details about the AHP method and MCDA in general refer to (Lootsma 1999; Kahraman 2008).

However, such a MCDA method can give reliable results only when judgment is made according to certain parameters, i.e. the decision model is deterministic. As the values of the task parameters (duration or cost) are uncertain in construction, the right decision model is a stochastic one. Accordingly, the results of the AHP method should be at times revised or another method, a stochastic one, should be used to choose between variants (Forman and Selly 2002). 24 The mathematical calculations are done using an AHP online software, available under: http://www.cci-icc.gc.ca/tools/ahp/index_e.asp


Figure 45: Added priority weights to configuration alternatives using AHP method

4.5. DISCUSSION

As construction processes show dynamic and changeable course of action, the flexibility in their representative models or their schedules is, consequently, needed. Therefore, several types of configuration templates were suggested to offer the needed flexibility in construction process models. Each template was presented as a configurable EPC fragment within an EPC process model. For every one of these templates a pseudo code was introduced that shows the corresponding change procedures in the process model graph. From the scheduling point of view, these procedures help to automate the adjustments of the process schedule that are still done manually in common scheduling tools.

From the BPM point of view, using these templates to describe configurable elements within an EPC process model enables avoiding the configuration problems of getting syntactically incorrect models after configuration. Such configuration problem can be encountered, for example, when configurable tasks are used to model the configurability in EPC process mod-els. The problem of getting unlawful models after configuration was discussed thoroughly by Recker et al (2006). They suggested some rules to insure getting syntactically correct EPC models from configurable models. Nevertheless, using the configuration templates offers a more direct way to get correct configured reference process models.

Although the concepts behind these templates can be implemented independent from a specific BPM technique, EPC was chosen as it offers graphical modeling elements that suit well the configuration of a process model sought in this work.

The hypothesis behind these templates is that in each process it may be possible to assign one or more configurable templates to every treatment (response action) of a frequent problem. This should succeed in the shape of an association {(Problem), (Treatment), (Template)}, which can be documented in the designed construction process model, i.e. on the model level. A process model that contains all the known exceptions in the shape of these associations is a


candidate to be a reference model of this specific process. Each reference model can be used to generate a process model and, consequently, a process model instance describing a single implementation of the construction process. Nevertheless, design process models that contain all the possible additional fragments using these configurable templates can be verx complex if many exceptional situations are associated to the process, especially if some fragments are related to each other. Consequently, it will be difficult to track and manage all the cases in such a graphically represented Configurable Reference Process Model (CRPM). Therefore it is reasonable to store the data, included in a CRPM, within a knowledge-base. This will ena-ble to query different aspects of the CRPM and to implement only the relevant fragments of it. However, extra data can be retrieved if they will be later required.

As new exceptional events may arise during the execution, i.e. the run time, of the process model instance, ad-hoc treatment may be needed. Anyway, configuration templates can still be useful in this case. A suitable one of them can be assigned to the chosen ad-hoc solution and consequently the needed adjustments of the process model instance will be done automatically. If it is thought that this new exceptional event may appear later in other instances of this model, it will be reasonable to document the implemented action on the reference process level in the shape of {(Problem), (Treatment), (Template)} association triple. Accordingly, the CRPM will be enhanced to a more comprehensive one (see the life-cycle of a reference process model in 3.8.2). It can also be possible for some exceptional events that more than one configuration template are applicable to integrate one response ac-tion in the process model. In this case the planner should decide the most appropriate template to be used for the current case.

5 . A KB FOR THE SPECIFICATION OF CRPMs 85

5. A KNOWLEDGE-BASE FOR THE SPECIFICATION OF CONFIGURABLE REFERENCE PROCESS MODELS

The configuration templates, suggested in chapter 4, offer an approach to represent the flexibility, needed in construction processes, in the shape of configurable fragments within the construction process models. The configurable fragments represent exceptional situations that may be adopted or skipped according to the current implementation case. Generally, a process model that contains, amongst others, all the exceptional cases of the process is a candidate to be a CRPM for this particular process. Nevertheless, if the process may have several interrelated exceptional cases the corresponding CRPM can be complex and, consequently, difficult to illustrate graphically, manage, utilize or to update. In this chapter a knowledge-base (KB) is suggested to manage CRPMs. The KB structure represents the elements of a CRPM with their attributes, the dependencies between them. This KB structure is designed as an ontology model that consists of several concepts related to each other via some properties. The configuration templates represent a fundamental part of the KB structure. In view of that, every exceptional fragment within the CRPM should be associated to a suitable configuration template that describes how to integrate it within the process model. The KB is formed by populating the ontology model with construction process data. Consequently, queries can be made to retrieve, update, and configure only the relevant aspects of the CRPM. Making it easier to manage and exchange the knowledge included within the CRPMs. In view of that, a conceptual example is presented later in this chapter to show the feasible usage of the KB founded on this ontology model. Lastly, a concluding discussion about the whole chapter will illustrate the benefits and the deficiency of the introduced suggestions.

5.1. BASIC CONCEPTS

Construction processes are totally dependent on the specific needs and resources of the current project, which are generally different from a project to another. Moreover, construc-tion projects include usually a lot of uncertainty, see 2.4. Therefore, it is mostly impossible to apply the exact process, as an explicit work route, in different projects. Consequently, a construction process cannot be considered as a structured process but as a semi-structured one as it has a dynamic course of action, see 3.3.2. However, the experience plays an essential role to manage the same process in different project contexts. The collected process-knowledge from different projects is, therefore, valuable for the effective process management. Unfortu-nately, this knowledge is mostly available implicitly in the mind of each person involved in the corresponding construction process, i.e. it reflects the gained experience in this process field. Such implicit knowledge will be lost if its owner will not be present in the company for a reason or another. Therefore, this knowledge should be documented explicitly to enable the interested fellows to share and use their experiences in a proper way.

Business processes are both knowledge demanding and knowledge generating. Therefore, they can be considered the initial point and the result of the Business Process-oriented Knowledge Management, see Heisig (2001) and Abecker (2004). Based on this, figure 46 shows the vision about the management of the Construction Process-oriented Knowledge as a

86 5 . A KB FOR THE SPECIFICATION OF CRPMs

Figure 46: Knowledge life-cycle for a construction CRPM


CRPM life-cycle. The initial point for this knowledge management is collecting data from all possible resources, e.g., projects history, experience etc. Only relevant data, i.e. process-oriented data, will be extracted and used to populate the KB of the CRPMs. The structure of this KB should represent elements, analogous to those in a CRPM. In case of need, the KB can be queried to retrieve the relevant process information in the shape of a CRPM, which should consider the special characteristics of the construction processes, e.g., unstructured and dynamic process context, by offering quick configuration features. Therefore, a corresponding structure of construction CRPM using ontological engineering concepts will be the main focus of this chapter. It will be shown how the configuration templates can be used as concepts in the ontology model to provide the needed flexibility in construction process models.

Furthermore, it should also be possible to configure the retrieved BPM according to the conditions of the process case at hand. For each use case of a specific process a different process model can be derived from its corresponding CRPM, see figure 46. After that, this process model will be instantiated by providing the process model elements by the parameter values of the use case at hand. The implementation of the process model instance will feed the user by information about the efficiency and completeness of the underlying process model. Accordingly, the needed optimization to the process model and to the CRPM will be done. This will insure a continuous update to the included CRPM-knowledge in the KB.

5.2. USING ONTOLOGY MODEL TO DESCRIBE THE SCHEMA OF THE CRPM

An ontology model (Gomez-Perez et al. 2004; Cardoso 2007; Davies et al. 2002; Hepp et al. 2007) can be defined as a formal explicit description of (1) shared concepts (classes) in a universe of discourse, (2) properties (slots) of each concept describing various attributes of the concept, and (3) restrictions (facets) on slots. The meaning of the ontology model vocabu-lary is formalized using description logics (DLs)25.

An ontology model together with a set of individual instances of classes (data) constitutes a knowledge-base. Accordingly, an ontology consists of two parts:

Set of axioms describes the structure of the model in the shape of classes and properties.

Set of facts describes concrete situations (individuals).

Generally, the development of an ontology model is not a goal in itself, but it is used as a commodity, i.e. data source, for the development of a large number of applications, such as tools for (1) knowledge management, (2) e-commerce, (3) intelligent integration information, (4) education, (5) database design and integration, and so forth.

According to Cardoso (2007), the origin of ontologies in computer science can be referred back to 1991, in the context of the research project “The DARPA Knowledge Sharing Effort”. The aim of this project was to devise new ways of constructing knowledge-based systems, so

25 Description Logics (DLs) is a family of knowledge representation formalisms that represent the knowledge of an application domain by first defining the relevant concepts of the domain (its terminology), and then using these concepts to specify properties of objects and individuals occurring in the domain.


that the knowledge-bases, upon which they are based, did not have to be constructed from scratch, but by assembling reusable components. This re-use applies both to static knowledge, which is modeled by means of ontologies, and dynamic problem solving knowledge, which is modeled by means of problem solving methods. Additionally, the emergence of the Semantic Web has caused a growing need for knowledge re-use, and has strengthened its potential at the same time (Gehre et al. 2007). Therefore, ontologies and problem-solving methods play an important role in this context.

Ontology languages were created as an evolution of existing knowledge representation languages. Accordingly, they were based on first order logic26 and on description logics. The internet needs led to the creation of the ontology markup languages. The syntax of these languages is based on existing markup languages such as HTML and XML. As examples of such languages; RDF, RDF schema, and OWL those were developed by the W3C (World Wide Web Consortium) can be mentioned.

Several ontology editors were introduced as tools to support the development of ontologies. Cardoso (2007) classified these tools in two groups as follows:

Ontology editors, whose knowledge models map directly to an ontology language, like SWOOP and KAON2 with OWL.

Ontology editors, whose knowledge models are usually independent of ontology languages, such as Protégé and WebODE.

Ontologies are considerably similar to databases as the ontology axioms are analogous to database schema and its facts are analogous to database data. But there are some main differences, which influence the choice between ontology and a database as a data source. For example, ontologies adopt open world assumption; in contrast to databases which adopt closed world assumption. For that reason, ontologies treat missed information as unknown, while databases consider it false. Moreover, each individual in a database has a single unique name, i.e. unique name assumption, while in ontologies an individual may have more than one name. Additionally, the ontology axioms behave like implications, i.e. implicit data can be inferred, but the database schema behaves as constraints on the structure of data. Therefore, it is reasonable to use ontologies, where it is not possible to assume complete information, e.g. modeling complex dynamic processes like construction processes. Other-wise, if complete information is available, e.g. booking systems, it will be more suitable and simple to use databases.

5.3. GENERAL REQUIREMENTS ON DESIGN CRPM FOR CONSTRUCTION PROCESSES

As it was mentioned before, construction processes depends on the specific needs of the project, which vary from a project to another. However, it is possible to classify processes in different construction projects according to their products. Nevertheless, different processes can have the same product as output and, therefore, these processes can be considered as alternatives to each other. Different aspects can be contemplated to choose one of these alter-

26 First Order Logic (FOL) is symbolized reasoning in which each statement is broken down into a subject and a predicate. The predicate defines the properties of the subject.


natives as the most suitable for the case at hand; such as cost, duration, complexity etc. As several standards, guidelines and norms are used in the construction sector to standardize and constrain its processes, it can be initially said that it is possible to describe each process as structured course of action with explicit routing. However, the presence of a lot of uncertainty in construction processes requires that these processes have to be flexible and changeable, i.e. the precedence relations should be minimized in the model context. Consequently, the need of structural description of each construction process to be used as a standard practice is faced with the needed flexibility in each process.

This contradiction requires a special solution for the construction processes. According to the observed behaviors of such processes and their needed specifications, a structural suggestion will be introduced in the following to solve this disagreement in needs. Accordingly, the tasks that are possibly needed to form the product of a construction process are classified in three groups:

The first group represents the core part of the process. The process core consists of tasks that form a deterministic structured routing in the process description, i.e. these tasks have predefined precedence relationships. Without at least one of the core part tasks, it will not be possible to realize the general product whatever are the conditions of the implementation case. Therefore, this core part will appear in all the process instances, i.e. these tasks are obligatory.

The second group contains tasks that may not be absolutely necessary in all the process instances. These tasks are (1) alternatives to the essential tasks or (2) auxiliary tasks as they add special features to the general product, which is produced by the core process part. These tasks are described in the process model as exceptional tasks, i.e. each one can be included in or excluded from the process model instance. This will be decided according to the specific context, i.e. the boundary conditions and the specific demands of the current case. The integration of the exceptional tasks in the process should succeed either according to pre-assigned configuration templates or according to an ad-hoc usage of one of the configuration templates.

The third group includes the known risk events that are possible to occur within the process execution and their known responses. An indication relationship should be built between these risk events and their affected parts of the process. The elements of this group should be integrated also, if feasible, according to pre-assigned configuration templates, as an association {(Problem), (Treatment), (Template)} or else according to ad-hoc usage of one of the configuration templates.

The last two groups are suggested to express the uncertainty in the construction processes. Together with the first group, these groups can build a process model that offers a solution for the contradiction between the standardization and flexibility in construction processes. Accordingly, a dynamic reference model, that encapsulates the current knowledge about its described process, can be built and later can be adapted to different instances according to the needs of each processed case.

On the other hand, the tasks in the process model should be specified to a level of detail that insures the needed flexibility to customize the process model to multiple projects. If the tasks are defined in too much detail, the process model becomes difficult to adjust and re-use.


However, by defining the tasks only at too high level, the process model cannot be used as a process knowledge source. The right level of detail cannot be generalized for all models that describe different processes, as it is related to the context and the specifications of each process. Therefore, it is the duty of the process modeler to decide, which granularity level is sufficient for each process model. For that reason, the modeling of the construction processes demands from the process modeler sufficient knowledge about the process to be modeled as well as sufficient knowledge about the modeling method that will be used, see Wamelink et al. (2002). Another way of modeling was suggested by the German Research Project “MEFISTO”. It states that the processes in a project should be modeled in different levels of detail on demand and the processes in different levels are to be linked together, according to e.g., spatial or temporal dependencies, in a hierarchical architecture (Scherer 2010).

5.4. STRUCTURE OF THE CONSTRUCTION CRPM AS AN ONTOLOGY MODEL

The ontology model is firstly described using the Meta model in figure 47. The components of this Meta model are:

The product: the aim of each process is to produce either tangible or intangible deliverables. Therefore, one of the most identifying criteria of a business process is the output product that it will form.

The process: this contains the concepts that are needed to represent a building process. The classification: according to the context and the level of description and privacy of

each process it can be classified to private, public or collaborative process model; the sense of these classification terms was described in 3.2.

The task: this component contains the concepts that are needed to represent different types of tasks that a construction process may include

The resource: this includes the tangible and intangible services that are needed to perform different process tasks.

The configuration: this includes some configuration concepts (amongst others the configuration templates that are presented in this work).

All the views of the ARIS house in figure 23 are included implicitly in Meta model, except the organization view, as it is not within the scope of this research work. The function view is embedded in the process and task components. While the data and the product/service views are embedded within the resource component. The relationships between these components of the Meta model in figure 47 are shown in a conceptual manner. The real internal and external relationships between the concepts of the components will be shown in the following.

Figure 47: The Meta model of the ontology model


In general, each construction process that produces a specific product can be executed using one of several methods. Each one of these methods can be used as alternative to the others to form the specific product of the process. Therefore, the abstract class Construction Process is associated to a class called Execution Method, using implemented by/implement properties, to express this (1 to n) relationship (figure 48). These two concepts with their internal properties build the process components.

The concept Product is associated to the abstract concept Construction Process from the process components using the inverse properties produce/produced by (see figure 48). Theo-retically, the needed CRPMs for a specific project can be retrieved from the KB according to their products. In turn, the products for the project can be obtained the project’s deliverable-oriented WBS. A CRPM produces a product, which is a deliverable in a low level in the WBS hierarchy. A deliverable in a high level in the WBS is a unique composition of deliverables on a low level in the hierarchy and, generally, such a deliverable cannot be modeled as a product of only one CRPM. The classification components include the Classification concept and three child concepts Private, Public, Collaborative, which inherit the properties of this parent concept.

Figure 48: The relationship between the construction process and the execution method in the ontology model

Each execution method consists of at least one task (figure 49). This is expressed in the task components by making (min 1 task) restriction (facet) on the property has that associates the Execution Method to the Task concepts. Every one of these tasks needs several resources to be executed. This is represented in the ontology model by associating the Task class from the task components to the Resource class in the resource components. The latter class is an abstract one and has the following five child classes: Manpower, Material, Equipment, Document and ICT tool (figure 49). The types of the needed resources differ according to the type of the product (tangible or intangible). Accordingly, Material and Equipment classes are only instantiated in case the process has a tangible product. On the other hand, ICT tool class is used to link the needed software application to each task; it is mostly instantiated for processes with intangible products. Showing different levels of detail of the construction CRPM is a part of the process knowledge that can be offered in the targeted CRPM. This can be realized in the ontology model as a task hierarchy. Accordingly, the property child of, which has the Task class as a Domain and as a Range as well, is used to build the hierarchy in the CRPM (see figure 49 and table 5). According to the suggestion in the previous paragraph 5.3, the tasks in task components are classified to essential, exceptional and one action solu-tion tasks. Essential tasks are the tasks that are needed in all the instances regardless the project conditions and without one of these tasks the expected product of a construction process will not be achieved. They are modeled using the Essential Task class, which is a child class of the Task concept. Exceptional tasks are the tasks that may be necessary in some process instances, but they can be skipped in other cases. These tasks in the ontology model


are represented within the class Exceptional Task, which is as well a child of the abstract concept Task. The properties of the Task concept will be inherited from the concepts Excep-tional Task, Essential Task and One Action Solution (figure 49). For example, the properties Child_of and has_Child will appear also in all the child concepts of the Task class. The inhe-ritance in the ontology model occurs between classes that have (is-a) relationships between them (shown in the figures as dashed arrows).

Figure 49: The assignment of resources to the tasks in the ontology model

Each problem that appears frequently, while executing a certain process or that may have a negative effect on the finished process product, should be documented within the CRPM, i.e. on the reference level, with all the known actions to deal with this problem. In the ontology model, this is done within the configuration components using the Problem class that describes the exceptional incidents, which may cause changes in the process model (figure 47). The Problem class includes the risks that may affect or interrupt the execution of a certain process. Generally, they may affect a certain task, a complete execution method, or generally a construction process, or even the product itself. To prevent the potential negative effect some procedures may be needed within the execution time of the process. Accordingly, the associations affects/affected by, between the Problem concept from one side and the Product, Construction Process, Execution Method and Task concepts from the other side, are used in the ontology model to represent this fact (figure 50).

As it was shown in 2.5.2, different treatment strategies can be used to mitigate, avoid, accept, or even to eliminate the effect of risky events. A suitable solution that belongs to one of these strategies should be used to handle the faced problem and, so, the planned process course of work may be changed accordingly. Such a solution may be a composite one, which means that different actions are needed in different positions within the process to handle the case at hand. Otherwise, the solution is one action or a sequence of actions that can be expressed as one action. In view of that, two concepts are introduced in the ontology model: Composite Solution within the configuration components (figure 50) and One Action Solution within the task components (figure 49). The first one is an abstract concept that is related to the One Action Solution concept as (Domain, Range), respectively, using the composed-from property. Consequently, a composite solution is configured from at least two “one action” solutions and


this helps to model the link of the configuration fragments through requirements that was shown in 4.4. The One Action Solution class is a child concept of the Task class. Therefore, the One Action Solution class will have the same properties of the Task class. So, some resources will be assigned for it, and it may in turn be affected by some risks etc.

The ripple effect of changes that has been mentioned in 2.6.4 is represented in the ontology model using the property has ripple effect that connects the class One Action Solution as a domain to the class Problem as a range. Accordingly, the treatment action of a specific problem may cause subsequent problems that will affect other parts of the process. Of course, the ripple effect of any change can even go beyond the process and affect other processes within the project, which are connected logically or chronologically with the studied process. This kind of multi-process ripple effect cannot be considered in the knowledge-base as these relationships among the processes will be only decided on the instance level of the construc-tion project and not on the reference level of the processes.

Configuration Template term is used within the configuration components as a superordinate class that includes two child classes: General Template and Interruptive Template, refer to two from the three groups of configuration templates. In turn, the General Template class has Insertion, Parallelism, Substitution, and Cancelation classes as subordinate concepts (figure 50). The third group, i.e. the reactive group, has templates that are only usable on the instance level and, therefore, will not be documented on the reference level. Nevertheless, if a demoli-tion method for a specific product can be documented on the reference level as a part of the process knowledge, which is usually rare in construction, then it may be useful to add the demolition template to the ontology model.

The One Action Solution class is associated to the Configuration Template class using the inverse property integrates/integrated according to. This means that the adopted solution will be integrated in the process instance based on one of the configuration templates.

If a composite solution is adopted to solve a certain problem, some changes will be needed in different positions of the process instance based on the linked One Action Solution instances and their coupled configuration templates. In a similar way, the Exceptional Task concept is connected to the Configuration Template concept. This means that an exceptional task will be integrated in the process model instance using one of the configuration templates.

Domain (Range) Property Range (Domain) Construction_process Produces (produced_by) Product Construction _process Implements (implemented_by) Execution_method

Execution Method Has (belongs_to) Task Product

Affected_by (affects) Problem Construction Process

Execution Method Task

Essential Task Predecessor (successor) Essential Task One_action_solution

Solve (solved_by) Problem Composite_solution One_action_solution Has_ripple_effect Problem Composite_solution Composed_from One_action_solution

Configuration_template Integrates (integrated_according_to) One_action_solution

Exceptional_Task

Table 5: Some main properties that relate the concepts of the suggested ontology model


Figure 50: The relationships between the configuration components and other ontology model components.


The precedence relationships between the essential tasks, i.e. the process core tasks, are

predefined using the properties (predecessor, successor) that have (domain, range) from the

type Essential Task (see figure 49). For these tasks, the events that link the tasks to each other

(based on the EPC notation) are not considered in the CRPM as these events are trivial and

will only cause undesired size growing of the model size. On the contrary, the Problem class

instances represent the non-trivial events that will trigger the response actions (One Action

Solution or Composite Solution) in case of occurrence.

Each one of these subordinate (configuration templates) concepts is associated to the Task

concept using a property reflects the relationship between the Exceptional Task and One

Action Solution instances from one side and the Task class instances that this specific

Configuration Template offers from the other side. For example, the Insertion concept as a

Domain is associated with the Task concept as a Target using Before/After/Between property.

This means that an Exceptional Task or One Action Solution instance will be inserted, for

example, “After” the targeted Task(s). All types of the used properties in the ontology model

that associate the configuration templates to the Task class from one side and to the One

Action Solution or Exceptional Task from the other side are listed in the following table 6:

Concept Property

Concept

(Abstract)

Property

C-template

groups

Property C-template Property

Concept

One

Act

ion

Sol

utio

n/ E

xcep

tion

al T

ask

Inte

grat

es/

inte

grat

ed a

ccor

ding

to

Con

figu

rati

on T

empl

ate

Is a

General

Template Is a

Insertion Before/ after/

between

Task

Parallelism Start - End

Substitution Start - End

Cancelation Target

Reactive

Template Is a

Demolition Target

Repetition Target

Interruptive

Template Is a

Action Target

Stop Target

Table 6: The properties relate the C-template concept to the Task concept.

Each one of the concepts in the presented ontology model has some attributes, which will be

populated by data according to the instances. For example, the class Task has the attributes

“ID”, “Name”, and “Description”. Each one of these attributes is assigned as a Data Type

Property that has the Range (String) and the Domain (Task). In the same way, such attributes

are assigned to all the concepts in this ontology model.


The configuration templates, suggested in the chapter 4, are included in the ontology model

within the configuration components to provide the needed flexibility in the CRPMs. By link-

ing exceptional tasks and problem-solutions to these templates, a quick adjustment of the

process model in the design or to its instance in the run time will be possible based on the

procedures of the connected template.

5.5. A CONCEPTUAL USAGE EXAMPLE

In the following, a simplified example will illustrate how to use a CRPM that is

included in the suggested CRPM ontology. Assume that the sought after process is the one

that produce (X) as a deliverable. Accordingly, several execution methods are available in the

KB. Execution method (2) is chosen according to different factors, e.g. time, cost, complexity

etc. In this execution method the following reference information are available:

The process core consists of several essential tasks (A, B, C, D) related to each other

in (predecessor, successor) relationships (see figure 51).

The exceptional tasks in the CRPM (E and F). The task E can be

integrated according to the insertion template that belongs to the general templates

group. The exceptional task E will be, therefore, integrated using the property “After”

that has the value “B” from the essential task list. There is no information available

about the integration of the other exceptional task “F” in the CRPM.

Two known problem events P1and P2 can be associated with the adopted execution

method (2). For the first problem P1 is the “One Action Solution” H available in the

CRPM. Two integration possibilities are suggested for this solution. These are: either

using the insertion template and, accordingly, H will be inserted after the essential task

B, or using the parallelism template and, accordingly, H will be inserted in parallel to

the essential task B. For the second problem P2 there is a “Composite

Solution” available. This consists of two “One Action Solutions” Y and Z. The

integration of these two solutions is suggested using the listed configuration templates

in figure 51.

The configuration of this reference information is based on the conditions and the characteris-

tics of the current implementation case. Let us assume that for this case it was decided that the

exceptional task E is not needed. On the contrary, task F will be adopted, but an ad hoc

decision should be made to decide how to integrate it in the process model. Consequently, it

was decided to integrate task F as a parallel task to all the other tasks in the process model.

The available time, cost, and resources for the current case have an essential influence on the

agreed ad-hoc decision.

The listed problems, that are associated with the execution method, play the role of a risk

checklist, which can be the initial point in the risk identification process, see risk

identification in 3.5.2. In view of that, a qualitative or quantitative assessment of the identified

problems will show the necessity to react to them. In this example, it is assumed that


according to the probability/impact matrix results the problem P1 had a low rating but the

problem P2 had a high rating. Therefore, the suggested composite solution for P2 in the refer-

ence process information should be included in the configured process case. This solution

includes two treatment actions. The first one is the task Y that should be inserted

before the essential task B. The second one is the task Z that should substitute the essential

task D. This new task Z plays in this case the role of an alternative of the task D. The

substitutive task Z was not preferred in normal cases because of, for example, its higher cost,

longer duration, complexity etc.

The resulted process model represents only one case from many that can be deviated from the

CRPM. The instance case (figure 52)of this process model will be afterwards provided by the

responsible actors and the available resources for each task. Accordingly, the estimated time

and cost to carry out each one of these tasks will be assigned. Many factors play a role to

decide the values of the instance parameters, such as the quantity of the product that the task

has to produce, available resources for each task, time and budget frames within the project.

Figure 51: The available reference information about Execution method (2) in the KB

The uncertainty, prevails the construction processes, makes it mostly rare to use the same process model instance, which is configured and instantiated in the planning phase, without making any adaptation within the execution phase. The adaptation of the process model instance may be caused by changes on the project, process, or even the task level.

These changes can be new, i.e. not documented before on the reference level. Accordingly, two types of changes can be differentiated. (1) ad-hoc changes that are needed only for a sin-gle implementation case. Therefore, these modifications should not be reflected as optimiza-tion of the CRPM describing this type of processes. (2) Evolutionary changes that should be documented on the reference level. The latter becomes necessary, for example, when new


laws come into effect or when new execution technologies are implemented by the construc-tion company and, therefore, the relevant CRPMs should be updated.

Figure 52: The execution method (2) after the configuration case

5.6. THE MANAGEMENT LIFE-CYCLE OF A CONSTRUCTION CRPM

As a customization of the reference process model life-cycle, shown in figure 28, the steps

that are needed to manage an already developed construction CRPM, according to the

suggested structure in this chapter, are shown in figure 53 as an EPC process model that con-

sists of the following groups:

Reference model selection and configuration (A); includes the choice of a suitable

CRPM from the KB and the adjustment of its configurable fragments to suit the case

at hand.

Process model instantiation and instance utilization (B); includes giving real values

for the parameters of the process model tasks and implementing it to execute the

process case.

Process instance evaluation and modification (C); the process model instance

should be evaluated according to the results of its implementation. Accordingly,

modifications may be suggested to adapt this process model instance.

Reference model evaluation and modification (D); the changes done on the instance

level, if any, should be evaluated to check their probability of occurrence in future

usage. In view of that, modifications may be needed to include the new acquired

knowledge in the respective CRPM. Nevertheless, a CRPM modification is not only

a result of the instance implementation (feedback data) but it can be as well a result of

external information (new laws, new technologies etc.).


Figure 53: the needed steps for the management of a developed CRPM

A B

C D


5.7. DISCUSSION

In this chapter an ontology model was introduced, which represents a suggested structure of CRPM for construction processes. The population of this ontology model with the available data of construction processes will form a CRPM-KB. Using such a KB within a construction company will enable the description of its process knowledge in a project neutral context. As a result, this could support decision-making and increase the intelligence of the construction processes. Consequently, the expenditure of time and money in the process design will be reduced.

Anyhow, it is not assumed that this presented ontology model is complete. It has here just the role of showing how the developed configuration templates can be included in a KB that describes construction CRPMs. However, an extended design of this ontology model may include several ontologies related to each other rather than a single one, like risks ontology, resources ontology, organization ontology, process ontology etc.

The usage of an ontological KB to manage construction CRPMs is beneficial for several reasons, such as:

A clearly defined semantics for the process models can be achieved by instantiating the elements of a CRPM from the concepts of an ontological KB. Accordingly, the ambiguity and the shortage in formality in process models can be avoided.

Storing the construction CRPMs in an ontological KB will enable making advanced queries when retrieving information which may even infer facts that were not explicit-ly created by the modeler of the CRPM.

In the shown conceptual example in 5.5, it was illustrated how to configure a CRPM accord-ing to the conditions of the current case. This configuration of a CRPM, which can be done in the planning and in the execution phase, succeeded using predefined or ad-hoc Configuration Templates. The predefined template connections in a CRPM represent a part of the acquired process knowledge. By assigning a Configuration Template in the CRPM to each exceptional process fragment the inclusion or exclusion of this fragment can be done automatically, i.e. the modification of the relationships between the elements will not need any more a manual intervention.

As it was mentioned before, developing ontologies is not a goal in itself. Accordingly, the construction CRPM ontology should be a commodity to develop process management soft-ware tools. Therefore, it is needed to improve the access to the knowledge included in the CRPMs by developing methods, which can support the choice, the configuration, and the composition of the relevant CRPMs. In view of that, the architecture of a software tool will be suggested in the next chapter. This tool will get use of the data in the construction CRPM on-tology and will play a central role of a construction process management approach that will be as well suggested in the next chapter. This approach should help to (1) speed up the design of construction process models and, consequently, the entire planning process, to (2) insure getting more consistent processes and to (3) accelerate the adaptability of the changed processes by offering ready solutions. Moreover, (4) it will enable to study the effect of specific situations as what-If scenarios during the planning phase without endangering the success of the process objectives.

6 . DESIGN AND IMPLEMENTATION OF SOFTWARE ARCHITECTURE 101

6. DESIGN AND IMPLEMENTATION OF SOFTWARE ARCHITECTURE FOR CRPM-BASED PROCESS MANAGE-MENT

A KB for configurable CRPM, founded on the developed configuration templates, was suggested in the last chapter. A KB is a passive data source that can be utilized by software systems. Accordingly, the management of the CRPMs included in the KB will need a software tool to perform the tasks that the user will ask from the KB. For that reason, a cyclic implementation approach that includes the CRPM-KB will be introduced in this chapter. The CRPM-KB management tool plays a central role in this approach. Accordingly, a software architecture, that describes the main elements of this tool as well as the interactions between this tool and other components of the cyclic approach, will be presented. The Unified Modeling Language (UML) will be used to specify, visualize, construct and document the components of the intended software architecture. Two different views of UML, the structural and the behavioral, will be used to demonstrate different aspects of the planned implementation. Following, the implementation of the suggested software architecture will be described in a nutshell. This includes programming the code for the needed feature, as well as, building the interfaces needed to interact with other components of the software architecture.

6.1. BASIC CONCEPTS

In the last chapter, an ontology model was presented that represents a suggested KB structure for a CRPM for construction processes. The effective use of this KB demands a software tool that will perform the tasks those the user will request from the KB. According-ly, the KB will be only used as a data resource in the background of this management software tool.

The whole implementation approach of this CRPM-KB is illustrated in the conceptual management cycle shown in figure 54. This cycle consists of three main components; the CRPM-KB, a Process-DB and the intended management tool. The implementation will start by searching the KB for the available CRPMs that produce a specific product. Based on the parameters of the current case, one from the suggested CRPMs, if any, should be selected. The selected CRPM will be then configured and instantiated. After that, the instantiated process model (IPM) will be saved to a process database. The process database is suggested here, instead of ontology, to save the planned process model on the instance level, since only deterministic information should be saved related to the implemented instance, see 5.2. The separation between the CRPM-KB and the Process-DB is needed here, as the first one represents a central data resource for all users, while the second one is just a local repository for each project. Accordingly, several databases may derive their instances data from the same CRPM-KB. The implementation of this IPM will validate the correctness of the original CRPM. Consequently, the need to modify its relevant data will be determined and possible improvements will be carried out.

During the implementation time of a IPM some exceptional events or new information may arise and, accordingly, changes will be needed in the already planned IPM (figure 55). The

102 6 . DESIGN AND IMPLEMENTATION OF SOFTWARE ARCHITECTURE

KB can be queried in order to find out if there is any relevant solution for the new condition. In the case that a solution is chosen from the KB, it needs to be configured, instantiated and integrated in the already planned IPM. Otherwise, an external solution will be sought after. This solution can be used for the specific IPM and can be as well integrated in the CRPM to enhance the process knowledge included in the KB.

Figure 54: The implementation cycle of a CRPM

After that, the adapted IPM will be saved in the Process-DB as a new version of the IPM. As new exceptional events may later appear, the adaptation cycle will be repeated to adjust the IPM; this iterative planning cycle is represented in figure 55.

Figure 55: The iterative adaptation cycle of a process model instance


Accordingly, the Process-DB can contain several versions from the same IPM if several changes in different times will be needed. This version controlling is a way of process documentation. It will enable the consideration of the evolution history of the process, within the implementation case, by comparing different process model versions with each other. According to the last two figures, the management software tool should control and manage not only the knowledge-base but also the database using some dedicated methods, e.g. selection, configuration, instantiation, documentation. So, in the rest of this chapter some important aspects of the structure of the planned software tool will be demonstrated using different diagrams of the Unified Modeling Language (UML), see (Ambler 2003; Fowler and Scott 1997; Marshall 2000; Rumbaugh et al. 2004). It was chosen as it is an open standard that supports the entire software development lifecycle.

6.2. DESIGN OF THE SOFTWARE ARCHITECTURE

The architecture of the suggested software tool consists of three tiers (Data, Application, and Graphical User Interface (GUI)). By using such a multi-layered architecture, the complexity of the interdependencies within the system will be reduced. Consequently, lose coupling between the layers and, in the same time, higher cohesion within each layer will be achieved. The data tier includes the Process-DB, the CRPM-KB, and a Run-DB. From its name, the Run-DB will be only created in the run time of the application and will include a copy of the IPM that is retrieved from the Process-DB. Accordingly, the procedures that will be done on the selected IPM will be done on the copy stored in the Run-DB and not on the original one in the Process-DB. Within this tier, different types of information, CRPMs and versions of IPMs, can be stored and retrieved. The retrieved information will be then passed through to the application tier for processing, and then, eventually, to the user. Communication between this tier and the application tier is needed and this should succeed using some kind of a query language.

The data tier keeps the comprised information neutral and independent from the application tier. This will improve the scalability and performance of the intended software tool.

The Application tier moves the process data between the two surrounding layers. Moreover, it performs the needed procedures, e.g., configuration tasks, and makes the required calculations on the retrieved process data. Amongst others, the Application tier has to do the following:

Query the CRPM-KB to get the relevant CRPMs, and to output the results to the GUI tier.

Configure the selected CRPM according to the preferences of the user. This should succeed using the procedures of the configuration templates presented in chapter 4.

Instantiate the configured CRPM and to store it after that to the Process-DB. Establish a new CRPM. This includes mainly, according to chapter 5, the essential

tasks and their precedence dependencies, the exceptional tasks and their needed configuration templates, the risk events, their known treatment solutions as well as their needed configuration templates.

Retrieve the process instance from the Process-DB. After that, to make the needed changes on this process instance version and to save it back in the Process-DB as the same version or as a new one.

Compare different versions of the same process instance and to show the results on the GUI tier using different methods, like EPCs, Gantt charts, or CPM calculations.


The GUI tier displays the processed and original information related to the process and, accordingly, allows the users to interact with the software application. This interaction can be a data request or a modification to the presented data. Accordingly, this tier communicates with other tiers by outputting results from the application tier in accordance with the user request or by data input to the data tier, through the application tier, according to the carried out user modifications.

6.2.1. PROCESS DATABASE

The schema of the Process-DB is represented in the UML class diagram (figure 56). The Process-DB includes IPM data. As it was mentioned before, it may be needed to document several versions of the same IPM in the Process-DB. This is represented in the UML class diagram as a (1 : n) association relationship between the classes ProcessInstance and Version. Each version should have at least one task. Accordingly, Version class is a collection or container of the class Task. The relationship between the Version class and the Task class is modeled as a composition. So, if the container “Version” is deleted, every task instance that it contains will be deleted as well. The precedence relationships between tasks in each version are built as successor-predecessor relationships. This is modeled as a recursive association within the class Task. The multiplicity of this recursive association is indicated as “zero or more tasks” at each end, as each task may have zero or more successors or predecessors. The task hierarchy is represented as a recursive composition relationship in the Task class. This indicates that all the subtasks that belong to one super task will be deleted when this super class will be deleted. As each task needs usually some resources to be executed, the Task class is related to the Resource class using the association “has”. This association shows that a task may need zero or more resources, as for example a Stop task will not need resources at all. The Resource class is an abstract one that is considered to be a super type of several subtypes (Document, ICT Tool, Person, Equipment and Material classes). Accordingly, a generaliza-tion relationship between the class Resource and all its subtypes is chosen as shown in figure 56.

Figure 56: the Structure of the Process-DB as a UML class diagram


6.2.2. STRUCTURAL VIEW OF THE SOFTWARE ARCHITECTURE

The main units of the software architecture are shown in the component diagram (figure 57). Here, two GUI components are presented. One is for the modeler to help to design and optimize the CRPMs in the KB. The other one is for the planner to help to select, configure, and instantiate CRPMs. The Application is separated as well into two components. These are: (1) the M-Application that includes the operations, which support the modeler tasks and (2) the P-Application that includes the operations, which support the planner tasks. The M-Application is connected to the CRPM-KB component using two interfaces, i.e. setData and getData. While the P-Application is connected to the same component using only the getData interface as the planner role has no right to design or enhance CRPMs.

The deployment of these components is illustrated in the deployment diagram in the same figure 57. The deployment is shown using four main components. These are the Desktop Modeler, the Desktop Planner, the DB-Server, and the KB-Server. Several desktop planner nodes can access simultaneously the DB-Server and the KB-Server. However, a DB-Server may exist for each project to hold its construction processes, while the KB-Server is a central one that will be used for several projects. This is indicated in figure 57 by the “1” in the KB-Server box and the “n” in the DB-Server box.

Figure 57: Component diagram of the software architecture units nested in the deployment diagram.

6.2.3. BEHAVIORAL VIEW OF THE SOFTWARE ARCHITECTURE

The management of the CRPMs includes two essential sides, firstly the design and the main-tenance of CRPMs. Secondly, the implementation of a CRPM for a special use case.

The interactions between these two management sides and other software objects (CRPM-KB, Process-DB, and Run-DB) are shown on the following UML sequence diagrams. These sequence diagrams demonstrate the behavioral view of the objects collaborations on the descriptor level. This includes the time sequencing of messages and the representations of the object activations.


6.2.3.1. MODELING A NEW CRPM

To design a new CRPM the modeler starts the CRPM Editor. Using this editor, the needed data to establish a CRPM will be entered. According to chapter 5, this data includes, but not limited to, the essential process tasks, the exceptional process tasks, the risk situations and their known solutions. Moreover, the suitable configuration template types to integrate each exceptional task as well as each risk situation should be assigned as well.

The names and the sequence of the used methods to set all this data are shown in figure 58. These data feeding methods will be repeated until all the planned data will be enumerated in their relevant lists. By saving the entered data the CRPM_KB will be activated by a query method that will try to save the new CRPM into the CRPM_KB. A response will be returned from the KB either if the saving was successful or not, i.e. an exception is thrown.

Figure 58: Modeling of a new CRPM, shown as a UML sequence diagram

6.2.3.2. SEARCH FOR A SUITABLE CRPM

The planner will search the CRPM-KB to find suitable CRPMs for the case at hand. Accor-dingly, a method in the application tool should be developed to retrieve the relevant CRPMs according to their products. So, the planner will be provided by a list of all the related CRPMs. This list should include just general information about each CRPM, such as the name and rough process description. By choosing one of these CRPMs by the planner, the applica-tion will retrieve all the available information from the KB concerning this specific CRPM. If no exceptions will be thrown, a recursive method “startRPM_Configurer()” will be called when the data of a specific CRPM has been retrieved. This method will open a RPM Configurer (a GUI element) that will be used to configure a process model from the chosen CRPM (see figure 59).


Figure 59: Search the RPM_KB for a suitable CRPM, shown on the descriptor level.

6.2.3.3. CONFIGURATION AND INSTANTIATION OF THE SELECTED CRPM

Configurable fragments in a CRPM can be adopted or skipped through the configuration. Therefore, two types of methods (skip, adopt) should be implemented. This is shown in the sequence diagram in figure 60 as two pairs of methods with an OR clause between the methods of each pair of them. These methods can be used repeatedly until the planner will trigger the method “finishConfiguration()”. This method will activate the Process Editor (another GUI element), which will show the configured CRPM data as a list of tasks with precedence relationships between them. The configured process can be instantiated using this editor by setting tasks durations, tasks start dates, and tasks end dates. The resulting IPM can be saved now to the process DB as the version (1), by default, of the process instance.

Figure 60: Configuration and instantiation of a selected CRPM.


The configuration will be made using the configuration templates presented previously in this research work. For that reason, the configuration procedures, shown as pseudo code in chapter 4, should be implemented as methods in the intended management tool.

6.2.3.4. EDITING AN IPM

As process changes may not only occur in the planning phase but also in the execution phase of the process. The support of such changes should also be considered within the planned software tool. The planning phase of a process will result in a configured IPM. This one will be saved into the Process-DB. If changes are needed in the execution phase, the process mod-el version will be retrieved from the Process-DB and a copy will be saved in the Run-DB. Several types of changes can be done on this copy such as change precedence relationships, add a task, delete a task etc. This changes that are asked by the planner will carried out as query-based methods by the process editor (GUI element). These query-based methods will be developed, as well, based on the configuration templates algorithms presented in chapter 4. After making the needed changes, the modified IPM version can be saved, either as a new version or as the same old one, into the Process-DB. Saving it as a new version will be done by getting the IPM data from the Run-DB, saving it to the Process-DB using the new version name and date, after that the Run-DB will be deleted, i.e. object destroy, and the Process Editor will be closed (see figure 61).

Figure 61: Making changes to a IPM and saving it as a new process model version.


6.3. IMPLEMENTATION OF THE DESIGNED SOFTWARE

The implementation of the designed software, presented previously in this chapter as descrip-tive UML diagrams, includes (1) the programming of the needed methods using the JAVA programming language, also, (2) the implementation of the Process-DB as a relational data-base and (3) the realization of the ontology model using an ontology editor. An overview of these 3 steps of implementation will be pointed out in the following.

6.3.1. PROCESS DATABASE

The Process-DB model is realized as a relational database. This is done using the Relational Database Management System (MySQL), as it can work on many different platforms and it provides, when it runs on a server, a multi-user access to the database. The handling and the administration of the MySQL database is done using phpMyAdmin, (figure 62) which is an open source tool that can perform different tasks, such as managing users and permissions or creating, modifying, and deleting of databases. Anyhow, the management of the data con-tained in the database is done using the statements of the Structured Query Language (SQL) through the JAVA management tool.

Figure 62: Screenshot from phpMyAdmin shows the database schema of the Process-DB.

6.3.2. THE CRPM KNOWLEDGE-BASE

The architecture of the CRPM knowledge-base was presented in chapter 5 as an ontology

model. Accordingly, an ontology editor, namely Protégé27, is used to realize the KB model

27 See, http://protege.stanford.edu/


and to hold its data. Protégé is an open source platform independent ontology editor and

knowledge representation and reasoning framework. It has been developed by the Stanford

Medical Informatics (SMI) at Stanford University as a standalone application with an

extensible architecture for creating and integrating easily new extensions. Protégé holds a

library of plug-ins that adds more functionality to the environment. The main modeling

elements of Protégé are classes, slots, facets and instances. Classes can be organized in class

hierarchies, where multiple inheritances are permitted, and slots can also be organized in slot

hierarchies. Protégé supports two main ways of modeling ontologies via the Protégé-Frames

and Protégé-OWL editors. The Protégé-Frames editor provides user interface elements and

knowledge server to support the construction of frame-based domain ontologies, the

customization of data entry forms, and entering instance data. Actually, one of the features of

the Protégé ontology editor, when compared with other ontology editors, is that the screen

layouts used to create instances can be designed. Accordingly, ontology developers can select,

which kind of forms will be presented, where the form fields will be located for each slot, etc.

Moreover, there are plug-ins for visualizing ontologies graphically such as the OntoViz and

OWLViz tab plug-ins. The screenshot in figure 63 shows graphically the taxonomy of the

classes of CRPM ontology model using the OWLViz tab.

Figure 63: Screenshot from Protégé shows the taxonomy of the classes of CRPM ontology model.


6.3.3. MANAGEMENT TOOL

The management of the RPM-KB and the Process-DB is done using a software tool, which is

implemented using the JAVA programming language. JAVA is an object-oriented and

platform-independent programming language. It has many free libraries that can be called in

the run time of a JAVA developed tool to get use of its specific reusable functionality without

extra complexity or expenditure of programming time.

The interactions between this management tool and the Process-DB are realized using

JDBC28. This API provides methods for querying and updating data in a relational database.

Accordingly, all the interaction request and return statements between the management tool

and the databases, shown previously in the sequence diagrams, are built as SQL statements

using the JDBC interface. MySQL provides connectivity for JAVA client applications via the

JDBC driver (Connector/J), which is used in this work. In view of that, the procedures of the

developed configuration templates are implemented using query and update SQL statements

within the JAVA management tool. The JAVA code, shown in table 7, represents a cut-out of

the programming code implemented in the management tool. It shows the procedures of the

configuration template “Parallelism” built as several SQL query and update statements. The

method starts by making a connection (session) with the targeted DB (here the Run-DB).

After that the statements needed to add a task in parallel to planned task(s) will be executed.

Then, the method will end by closing the connection object and so the JDBC resources will be

immediately released. This connections and disconnections with the database were shown in

the descriptive sequence diagrams as several activations of the DB object (figure 61).

The queries and the update of the data in the RPM-KB are utilized using SPARQL29 query

and update-based statements. SPARQL is a graph-based RDF30 query language that can be

used to express queries across diverse data sources. The returned answers of SPARQL queries

are shown as result sets or RDF graphs.

To make it possible for the management tool to interact with the CRPM ontology as well as to

use other functions provided by different Protégé plug-ins, a Java API, called JENA31, can be

used to access all the ontology terms. JENA is an open source JAVA framework for building

semantic web applications and in the same time it is an API for RDF that includes a SPARQL

query engine.

28 JDBC (JAVA Database Connectivity) is an Application Programming Interface (API) for the JAVA language. It defines how a client may interact with a relational database. 29 http://www.w3.org/TR/rdf-sparql-query/ 30 RDF states for Resource Description Framework. It is a family of W3C standards for the modeling and inter-change of information that is implemented in web resources. 31 http://jena.sourceforge.net/


// pararallel template method public void insertParallelTask( string processName, string versionName, string newTask, long start, long end, string desc, string startTask, string endTask, arraylist<task> allTasks, task[][] pathArray) { openconnection(); preparedstatement st1 = conn.preparestatement( "select process.id from process where process.name = ?"); st1.setString(1, processName); // add the changes to the database resultset p_id = st1.executeQuery(); p_id.next(); string processID = p_id.getString(1); st1 = conn.prepareStatement( "select version.no from version where version.id = ? and version.version_no = ?"); st1.setString(1, processID); st1.setString(2, versionName); resultSet v_id = st1.executeQuery(); v_id.next(); string versionID = v_id.getString(1); // insert the new task to the RTDB st1 = conn.prepareStatement("insert into task values (?, ?, ?, ?, ?, ?)"); st1.setString(1, taskid); st1.setLong(2, start); st1.setLong(3, end); st1.setString(4, newtask); st1.setString(5, desc); st1.setString(6, versionid); st1.executeUpdate(); // register version change RTDBconn.setTaskChange("version"); // add the dependencies st1 = conn.prepareStatement("insert into successor values (?, ?)"); preparedStatement st2 = conn.prepareStatement("insert into predecessor values (?, ?)"); for (task task : allTasks) { if ( ! task.name.equals(newTask)) { continue; } // successors for (task successor : task.successors) { st1.setString(1, task.id); st1.setString(2, successor.id); st1.executeupdate(); st2.setString(1, successor.id); st2.setString(2, task.id); st2.executeupdate(); } // predecessors for (task predecessor : task.predecessors) { st2.setString(1, task.id); st2.setString(2, predecessor.id); st2.executeupdate(); st1.setString(1, predecessor.id); st1.setString(2, task.id); st1.executeupdate(); } } st1.close(); st2.close(); conn.close(); }

Table 7: Part of the Parallelism template method, in JAVA, showing how to change the data in the Run-DB


6.4. DISCUSSION

The management tool that was realized in this work gets use of the CRPM-KB, presented in chapter 5, as a data source, and plays the role of the proof of the useability of the configuration templates developed in chapter 4.

An overview about the design of this tool architcture was presented in this chapter, from the structural and beavioral points of view, using UML diagrams. After that, the implementation of the designed software tool elements was briefly demonstrated. Although this tool was designed as a stand-alone software prototype but its elements can be theoretically integrated with a third party project management tool.

Such a tool offers the possibilty for construction companies to document their knowledge in a explicit process oriented way, i.e. as CRPMs. This can help to (1) optimize the acquired knowledge, to (1) communicate it with other partners or work collegaes, and to (3) resue it in future similar cases. In view of that, a planner can prepare process schedules starting from a respective CRPM. This can assist to avoid planning errors resulting from (1) forgetting some important details or (2) the limited experience with specific processes. The Process Editor (tool component) can be used as a scheduling tool. Thus, process schedules can be generated and changed using the configuration dialog boxes of the process editor. The different resulting versions of the process can be saved and compared to track the evolution of the process execution.

However, the validity and usefulness of the major concepts behind this management tool should be proofed using real construction process cases. This can demonstrate the range of applicability of the developed methods and the limitations in the suggested approach. Therefore, the next chapter will show how to build CRPMs from real construction processes and how to use a CRPM from the KB to plan process cases in different conditions.

114 7 . CASE STUDIES

7. CASE STUDY

In this chapter, several scenarios that represent real construction process situations are introduced. These scenarios cover different steps of the CRPM life-cycle such as (1) the design of a construction CRPM, (2) the configuration and instantiation of a particular CRPM for a specific construction process case,(3) the issue when ad-hoc changes to a specific process model instance are needed and (4) the potential consequent enhancement of the relevant CRPM. The possible exploitation and the limitation of the developed concepts, which are realized with-in a management software tool, should be pointed up via these scenarios. Conse-quently, a better evaluation of the whole research work as well as a more realistic outlook of the possible future research that is based on this work can be achieved.

7.1. SCENARIO 1: DESIGN OF A NEW CRPM

In this scenario the modeler has the task to form a CRPM according the developed concepts in this research work. The target construction process is the building of a retaining wall. This process has the tangible product “Retaining Wall”.

According to the ontology model of the CRPM described in chapter 5, the modeler will start by giving a name to the CRPM. This name should point to the product of the process, e.g., Construct a Retaining Wall. Several types of retaining wall exist and they can be even built in a type-hierarchy. For each type different execution methods can be used to construct it. For example, a Retaining Wall (RW) can be from the cantilever type. This type can be executed using:

Cast-in-place Reinforced Concrete (RC) method. The product in this case is either (1) a cast-in-place RC RW or (2) a counterfort RC RW. Each one of these types represents a sub-type of the Cantilever RW.

Precast RC method. The product in this case is precast RC RW and it is a sub-type of the Cantilever RW.

Plain concrete method. The product in this case is a gravity retaining wall and it is as well a sub-type of the Cantilever RW.

Only one execution method will be detailed here, namely, the construction of a retaining wall as a cantilever one using cast-in-place RC. Accordingly, the next step is to list the tasks belonging to this execution method. These tasks are classified to two groups, i.e. the essential and the exceptional tasks.

According to the experience in executing similar types of processes in previous projects, the modeler considered the following tasks as essential tasks in the level (1) of granularity within the CRPM (Construct a Retaining Wall) and the execution method (Cantilever RW using cast-in-place RC) :

Excavate the footing pit Concrete the RC base slab Concrete the RC wall Backfill the retaining wall

These tasks are considered essential (figure 64) because without any one of them the product “Retaining Wall” with its simplest specifications will not be achieved. The precedence relationships (predecessor, successor) between these tasks are also determined in the CRPM. Definitely, more detailed levels of granularity for each one of these tasks can be modeled within this CRPM.

7 . CASE STUDIES 115

Figure 64: The EPC model (right) represents a possible construction process of the Cantilever RW (left). For simplicity trivial events are skipped.

Exceptional tasks are the tasks that are not needed in all the process model instances (alternatives, or auxiliary tasks). The planner should choose either to include or to exclude these tasks from the process schedule plan according to the specific condition of the case at hand. The CRPM modeler should decide which tasks may not be needed in all the instances of the process (Construct a Retaining Wall). In view of that, e.g. the Provide Shoring task, by which sheet piles will be driven into the ground to insure the stability of the excavation pit while construction work, is considered an exceptional one. This is because sheet piles are only needed in some excavation areas of the retaining wall. In other words, if a retaining wall will be executed in a region, where the difference between the original ground level and the bottom of the excavation pit is lower than a specific critical height, then (Provide Shoring) task can be skipped as neither the stability of the excavation pit nor the security of the building workers are threaten. This task will be integrated with the essential process tasks using a configurable template link. Therefore, the configuration template “Insertion” is used to integrate the exceptional task (Provide Shoring) with the essential part of the CRPM using the property (before) that has a range concept (Task = Excavate RW pit). However, the task (Provide Shoring) could also be modeled as a response to the excavation stability risk. How-ever, in view of the fact that the purpose of sheet piles is well known the modeler decided not to mention the excavation stability risk. The experience gained from past projects shows that the failures or damage to retaining walls were mostly due to the insufficient drainage of the backfill. This can be ascribed to the hydrostatic pressure from pore water accumulated during or after rainstorms, which can greatly increase the thrust on the wall. Therefore, for The Retaining Wall as a product the CRPM modeler should document the ground water in poorly drained backfill soils as possible risk origin. However, a retaining wall can be designed to withstand the extra pressure caused by the ground water. Nevertheless, it is desired to provide backfill drainage rather than to design the wall for the large lateral pressure that results from a saturated backfill (Nilson et al. 2003). The ground water risk is modeled as an instance of the Problem concept, its known response treatment methods are modeled as instances of the One Action Solution concept and their integration methods are modeled as configuration templates. In view of that, the model-ing will be in a form of an association between the association triple {(Problem), (Treatment), (Configuration Template)} and the product (Retaining Wall). The backfill drainage, as a treatment for the ground water problem, can be provided using various methods, for example:


Weep holes consisting of 75-100 mm diameter pipes embedded in the wall can be spaced horizontally at 1.5 to 3 m distances. Also, very coarse gravel should be placed in the vicinity of each weeper to facilitate drainage and prevent clogging.

A longitudinal drain with crashed stone gravel around it can be provided along the rear face of the wall. The drain may be discharged naturally at one end of the wall. Other-wise, few intermediate weepers should be considered to discharge the collected water.

A combination of the last two solutions to provide a better drainage system. Based on this, the CRPM that represents the construction of a retaining wall, as cantilever one using cast-in-place RC, has considered all these backfill drainage solutions (figure 65). The configurable fragments in the CRPM are modeled using different configuration templates. The configuration template “Parallelism” is used to integrate (Provide weep holes), as one action solution, in the CRPM using the properties (start, end) that have the values (start: Task= Concrete RC Wall, end: Task=Concrete RC Wall). The configuration template “Insertion” is used to integrate (Provide Longitudinal drain), as one action solution, in the CRPM using the property (after) that has the value (after: Task= Concrete RC Wall). As one of these two solutions or both of them can be adopted to solve the ground water risk that may affect RWs, a composite solution called drainage system is also modeled within the CRPM-KB (shown in figure 65 using the requirement R(3)). This composite solution is formed from two “One action solution”. These are (Provide weep holes) and (Provide Longitudinal drain) tasks. Accordingly, the process planner can use one of the listed one action solutions or the composite solution to handle the possible ground water problem.

Figure 65: A CRPM (right) represents the construction process of the Cantilever RW (left). For simplicity trivial events are skipped.


The CRPM modeler uses the protégé editor to save the collected data into the CRPM-KB in the shape of a CRPM. This is done using several forms that are prepared as input windows. For example, in the screenshot in figure 66 the execution method editor is represented. Gener-al information about each execution method within “The Construction of a Retaining Wall” CRPM can be managed, such like the process classification, the essential tasks, the exceptional tasks, the possible associated problems within each process.

Figure 66: a screenshot shows the execution method editor in the RPM-KB.

In the screenshot in figure 67 essential task editor is represented. It helps to manage the details of each one of the essential tasks, such like the precedence relationships (successors, prede-cessors), a description for each task, the granularity level and the hierarchical relationships with other tasks etc.

Figure 67: a screenshot shows the essential task editor in the RPM-KB.


7.2. SCENARIO 2: CONFIGURATION AND INSTANTIATION OF A CRPM

Based on the CRPM developed in the first scenario, the configuration and instantiation of a CRPM to suit the requirements of a specific case of use will be demonstrated in this scenario.

Here, the configuration means to decide, according to the conditions of the current use case, for each exceptional task within the CRPM if it will be excluded or included in the derived process model. Additionally, if the process risks will be considered, i.e. the probability of occurrence and impact of each risk is higher than the agreed thresholds, then a suitable solution should be chosen, maybe even from alternatives, and included in the derived process model.

The instantiation of the derived process model is limited in this work to assign time attributes to the tasks of the process model, i.e. durations, start and end dates.

This scenario is about a process that is a part of a road construction project. For the purpose of configuration and instantiation it is assumed that processes in this project are to be planned. Therefore, the project is represented in a deliverable-oriented work breakdown structure. The leaf deliverables are considered the products of the project processes (figure 68). A part of these products is the construction of several retaining walls (RW1, RW2 etc). As the designed road works will need big earth moving tasks, i.e. excavation and backfill, to insure the de-signed route and grades of the road, several protection retaining walls are needed in different backfill and excavation areas of the project. The structural engineers chose cantilever retaining walls as the type to be used in this project. The details of the structural designs of the retaining walls (locations, dimensions and reinforcements) are provided within the detail plans of the project.

Figure 68: A part of the deliverable-oriented work breakdown structure of the road construction project.

The planner of the project has now the task to schedule when to do each deliverable within the project and to point the tasks and their dependencies needed to realize this deliverable. The scheduling is actually controlled by several aspects, such like the available time frame, the offered budget, the quantity of work, and some other logical and technical conditions. On the other hand, the correctness and comprehensiveness of the schedule is based on the experience of the responsible planner.

To plan the execution of a specific retaining wall within the project, the CRPM-KB can be searched for a CRPM concerns the construction of cantilever retaining walls. This CRPM includes the experience that the construction company gained in doing such type of work in past projects or even it includes the bought expert knowledge in this field.

The data about the CRPM (Retaining Wall) will be retrieved from the RPM-KB using the SPARQL query statements included within the methods of the management tool. Firstly, a request will be made to query the RPM-KB about the availability of a relevant CRPM


according to some keywords. In the case of a positive response, the related CRPM details will be imported to the RPM_Configurer to make the needed configuration tasks on them. Some examples of the implemented SPARQL queries are shown in table 8.

Target Used SPARQL query

Retrieve the essential tasks of the chosen CRPM

SELECT ?EssentialTask WHERE { CRPM:cast_in_place_retaining_wall CRPM:HasEssentialTask ?EssentialTask.}

Retrieve the configurable tasks of the chosen CRPM

SELECT ?ConfigurableTask WHERE{CRPM:cast_in_place_retaining_wall CRPM:HasConfigurableTask ?ConfigurableTask.}

Table 8: Examples of the used SPARQL query statements to retrieve the CRPM data from the KB

One of these retaining walls (RW 1) will be executed in a backfill area. Therefore, it can be constructed without a need for shoring as in this case the excavation pit will not be deep enough to endanger its stability. Accordingly, the planner will exclude the configurable task “Provide Shoring” from the process model instance. A drainage system was not specified in the RW drawings, i.e. it was unaccounted as an error or negligence from the designer. In this case, the RPM gave a hint here to this important detail. In view of that, the planner decided to adopt the weep holes as an adequate one action solution for the ground water problem, since the project is located in a relatively dry area (the average annual precipitation is less than 400 mm). This insertion of this new task in parallel to “Concrete Wall” task is a proactive treatment as the action was implemented before any negative consequence has been occurred (figure 69).

After configuration, the duration of each task in the configured CRPM can be decided according to the work quantities, the available resources etc. As each task is related to one or more tasks using (predecessor, successor) relationships, the start and end date of each task can be decided be giving one value (start or end date) to only one of the process tasks.

Figure 69: the configured deterministic CRPM (Construction of a Retaining Wall) according to the use case


The description of each task, which may include technical details or explanatory notes, can be edited as needed. As a result, a schedule of the process instance is presented and can be visualized using traditional scheduling methods such like Gantt chart. Now, the configured and instantiated CRPM according to the current use case conditions will be saved into the Process-DB as version 1 by default, i.e. the first version of the process model instance.

7.3. SCENARIO 3: CHANGES TO THE PROCESS MODEL INSTANCE

The configured and instantiated CRPM is now a part of the road project baseline schedule, i.e. the execution of the RW1 will be done according to it. Now, assume that the execution of this RW1 started and the second work step in this process has already finished, i.e. the concrete RC base slab has been casted. Later, after a rainy weekend the project team returend to the project site to continue the planned work and they discovered that RW1 pit is full with water. Consequently, the planned concrete RC wall task can not be started as planned. Obviously, since the RW1 excavation pit forms a low point in the project site, surface water is likely to collect in the bottom of the excavation.

According to Cashman and Preene (2002) such a surface water problem may arise because of one or more of the following reasons:

Precipitation into the excavation Precipitation runoff from surrounding areas Waste water from construction operations such as concreting or even from washing

down of equipments.

Whatever the source is, if surface water is allowed to pond in the excavation it will impede efficient excavation and construction and it will undoubtedly cost the project time and money. For that reason, the site engineer is now in a problem and needs a solution to be able to continue the planned work.

Using the terminology of this work the situation can be described as follows:

“surface water as a disturbance has interrupted the progress of the RW1 process and a reactive treatment solution should be implemented to(1) elemeinate this problem, to (2) continue the work on this product RW1and to (3) prevent the surface water risk from occuring again later”.

In view of that, the site enginner has the following ad-hoc idea to treat the present problem:

“The water inside the excavation pit has to be pumped away and as a proactive risk treatment any future water runoff should be collected aside of the pit and pumped later away”.

In this way, the rest of the process work will not be disturbed by the surface water. To realize this idea an adjacent sump to the RW1 pit should be dug to a deeper level than the main excavation and should be maintained in its original form throughout the process period. After that, a robust pump, capable of handling solids-laden water, will be used to pump the collected water away from the sump.

The representation of the ad-hoc changed work course of the process model instance is shown in figure 70. By using the process editor, the version (1) of the process model instance can be modefied and, consequently, saved in the Process-DB as a new version (2) with the time stamp and the name of the modifier.

The configuration template (insertion) is used here in ad-hoc way to insert a stop task with duration equal to that caused by the disturbance by the surface water. Also this configuration


template is used to insert the “Provide sump pump” task as a treatment solution for the mentioned disturbance. The insertion of the new task “Provide sump pump” means that some relationships have to be changed between the existing tasks and some new relationships have to be established. To carry out these changes the insertion dialog box of the Process Editor (figure 70) is used. The needed dialog inputs are (1) the name of the predecessor task(s), (2) the attributes of the new task (name, start date, end date, and description), and (3) the insertion reason. The different versions of the process schedules saved in the Process-DB can be compared with each other to track the development of the process while execution. For example, the Gantt chart in figure 70 compares versions (1 and 2) of this process model instance.

Figure 70: modified version of the process model instance representing the construction of RW1

The presented surface water disturbance has interrupted the process after the task “Concrete RC base slab” has been finished and before the successor task “Concrete RC wall” has started. Nevertheless, it can be also the case that the disturbance will interrupt exactly one task by occurring between its start and end dates. In this case a deeper level in the hierarchy is needed where the interruption may be assumed to occur between two tasks and not through any one of them. Based on this, if the surface water disturbance will interrupt the task “Concrete RC base slab” in the level (1) of granularity then a deeper level in the hierarchy will be sought. Assume that the disturbance occurred after the reinforcement of the slab has been finished. Consequently, the disturbance and the treatment action will be located between


the tasks “place the reinforcement” and “Cast RC base slab” on the level (2) of the process hierarchy (figure 71).

Figure 71: The treatment of the (surface water) disturbance shown on the level (2) of the hierarchy.

7.4. SCENARIO 4: CRPM ENHANCEMENT

The last disturbance case (surface water) was not included in the CRPM in the shape of an association triple {(Problem), (Treatment), (Configuration Template)} with the essential part. Therefore, a planner or a site engineer with limited-experience, who depends fully on the CRPM developed in scenario 1, will miss this important detail. Consequently, some delay and extra costs will be the consequences if this disturbance will occur.

As this problem is a frequent one that may occur whenever excavation is needed, it will be reasonable to document it with its known suitable treatment actions on the reference level of the process, i.e. in the CRPM. Therefore, the CRPM modeler should be notified to make the needed enhancements to the respective CRPM for future use. To extend the knowledge included in the CRPM concerning the surface water problem, the CRPM modeler should have experience in this field or at least should be able to acquire the needed data from technical resources.

In general, surface water must be controlled to ensure that the area of excavation and construction is always workable. The basic rule of good practice is to collect and control the surface water run-off as soon as, or better even before, it enters the area of work. Generally, rain water or discharges from other construction tasks are main sources of surface water. The treatment of the surface water in a proactive way can be made by digging collector ditches on the high ground. The ditch should lead the water away to discharge points, which could be pumped by sump pumps lower down the slope. To achieve this, two methods can be used:

Open ditch method that should be used only where the presence of open ditches does not hinder construction work. Cleaning must be regularly applied to reduce the effect of clogging by suspended particles in the surface water.

As an alternative, agricultural ditch can be used. The ditch surface must be also regularly scarified to reduce the effect of clogging.


The sump pumping can be separately included in the CRPM as a reactive treatment action as this method allows water to enter the excavation, from whence it is pumped away.

An abstraction about the way of inclusion of the enhancement data, according to the CRPM terminology, in the RPM-KB is shown in the table 9. Form this table it can be concluded that:

The modeler considered that the surface water threatens not only the excavation task but the whole process “Construct a Retaining Wall”.

The treatment actions are shown as one action solutions, which can be refined to give more details about the treatment method.

Both solutions “Provide open ditch” and “Provide agricultural ditch” can be integrated in the process using the insertion template. The solution should be carried out before the excavation of the RW pit will start (proactive treatment).

“Provide sump pump” task can be integrated in the process using the interruptive action template. The target task of this template is set on “unknown” as the surface water can interrupt any of the tasks within the “Construct a retaining wall” process.

Table 9: The used terminology to enhance the CRPM by surface water treatment data

7.5. SCENARIO 5: RIPPLE EFFECT OF CHANGES

This scenario shows another construction example that includes the construction of a new residential building, which consists of a basement and several repeated stories. Assume that in one summer the building pit was excavated, the RC work in the basement has been finished (footings, walls, columns etc) and the backfill as well. In the beginning of the rain season, other concrete tasks have started in other stories of the building, in parallel to that, some finishings tasks are going on as planned in the basement, e.g. brick work and plastering.

Once after a heavily rainy weekend the finishings crew found that there is about 20 cm water gathered in the basement. The reason was ascribed to ground water seepage from the walls or from the floor of the basement (figure 72).

The groundwater disturbance was not in consideration, maybe because the site exploration was done in the summer of a dry year, so it was concluded that no groundwater risk may affect the basement of the building and, therefore, normal external wall isolation will be enough to handle the moisture problem in the surrounding ground.

Generally, such groundwater seepage could happen at any time within the project execution or even after putting the building into service. In the execution time of the project this disturbance can interrupt and stop any ongoing task in the underground area until some reactive action will be done to handle this problem and its effects.

In this scenario it is assumed that this event has disturbed the finishings processes (brickwork and plasterwork) in the basement of the building.


Figure 72: The situation of the building basement before (left) and during the rainy season (right).

A suitable treatment should be searched to solve the actual problem. A possible solution is by excavating a deep trench around the building, installing drainage pipe, building manholes and after that backfilling the trench with filter materials, (figure 73 left side). The collected water will be discharged naturally at a point far from the building. This solution will prevent that more ground water will enter the basement as it will lower the ground water level in the build-ing area. Moreover, to remove the already collected water in the basement it may be needed to use pumps to discharge it away. Afterward, the stopped finishings processes (brickwork and plasterwork) in the basement can be resumed.

An alternative solution can also be adopted to handle the groundwater problem. For example, a number of deep wells will be excavated around the building and a pump will be installed at each well to withdraw the groundwater and lower its level in the whole building area, (figure 73 right side). The pumps will be adjusted to work as the table of the groundwater will reach a critical level that will threaten the building.

However, it is assumed in this scenario that the ground water will not damage the already done parts of work in the basement. Therefore, the stopped processes can be continued with-out a need for any rework or repair.

Figure 73: Two alternative treatment solutions suggested for the groundwater seepage problem.

One of these two solutions can be implemented as a proactive or reactive treatment solution for the groundwater seepage. The ground water seepage as a problem and the proposed treatment solutions can be saved in the RPM-KB as an association triple {(Problem), (Treat-ment), (Configuration Template)}. However, to the CRPM of which process this triple should be linked in the RPM-KB?. Actually, there is no direct logical relationship between ground water problem and brickwork or plasterwork processes. Accordingly, it cannot be said that a ground water problem threatens any one of these processes. Consequently, this problem can-


not be documented on the reference level of these processes. Maybe, it is reasonable to link this association triple to the excavation process of the basement. In this way the ground water seepage risk should be treated in a proactive way, i.e. before the excavation starts, to ensure that no consequent interruption because of this risk will occur. If this risk will not be dealt with in a proactive way, i.e. it was unforeseeable according to the initial studies, its effect may go beyond the excavation process to affect other related processes, e.g. in the case of this scenario spatially related processes were affected by the risk belonging to the excavation process. The implementation of one of the suggested solutions to handle the ground water seepage risk will result in drawdown the ground water level. For a while, this can be seen good as the implemented solution will get rid of the ground water seepage risk. Nevertheless, drawdown of water levels can have detrimental effect on the adjacent buildings. This effect can vary from minor to major settlements in the footings and consequent cracks or even collapse of the adjacent buildings. Such kind of consequent problems can be considered as a ripple effect of the ground water seepage treatment. Anyhow, the effect can be minimized by using artificial recharge systems to reduce the drawdown of ground water level out of the project area.

The ground water seepage data stored in the RPM-KB should be extended to cover the risk of settlement in adjacent buildings. This is done by linking the One Action Solution instances “Provide deep wells with pumps” and “Provide deep trench with drainage pipe” to the instance of the Problem concept “Settlement in adjacent buildings” using the property “affected by problem”. In turn, the Problem instance “Settlement in adjacent buildings” is linked to the One Action Solution instances “Provide artificial recharge system” using the property “solved by”. This is shown in the sub-graph in figure 74, which is illustrated using the OntoViz tab in protégé.

Figure 74: A screenshot shows a sub-graph of the RPM-KB contains the (ground water seepage) related data.


7.6. DISCUSSION

It was shown in this chapter that the developed approach can be used to support all phases of the CRPM life cycle. The CRPMs can help as means of the process-oriented knowledge management of construction processes. Consequently, by using the related CRPMs as the starting point within the project planning phase the possibility to miss an important detail will be decreased and more reliable schedule plans can be achieved.

However, as this work has concentrated on the process level within construction projects, there is still some deficiency when the relationships will go beyond the process itself. The description of the dependencies between the processes documented in different CRPMs is not possible in the suggested RPM-KB structure. Therefore, a CRPM cannot cover all types of exceptional situations, which the respective process may face.

The CRPM was intended to model the production of the repeated leaf products within a construction project, e.g. according to a deliverable-oriented WBS. Describing deliverables on a higher level in the product hierarchy as CRPMs have some positive and negative aspects. For example, a link between the ground water seepage risk and the product Basement in the RPM-KB will infer all the products, which have the Basement as a superordinate product and may be affected by this risk (figure 75). However, it is mostly impractical to model a superordinate product on the reference level as this product is just an aggregation of different types and quantities of sub-products. The content of such an aggregation differs from a project to another. Therefore, such process models cannot be usually standardized.

Figure 75: A part of the mixed-form WBS of the residential construction project

8. CONCLUSIONS AND FUTURE RESEARCH 127

8. CONCLUSIONS AND FUTURE RESEARCH

8.1. CONCLUSIONS

The novelty in the presented work lays in the development of the configuration templates using business process modeling techniques. These configuration templates consider the characteristics of construction processes and, in the same time, they ensure getting syntacti-cally lawful process models after configuration. Accordingly, this has enabled to design a CRPM structure for construction processes and, hence, to model the uncertain (exceptional) parts of the construction process as configurable fragments within the CRPM. Such type of templates is actually new in the field of business process modeling and it represents the starting point of the whole management approach for the construction processes, which is developed in this research work.

This approach was initiated by the need to represent the uncertain fragments within the course of a construction process. The sought-after representation was intended in the form of configurable fragments within the model of the construction process. Subsequently, this led to develop the configuration templates. Each template describes a general type of change in the structure of a construction process model. One suitable configurable template can be used to model each exceptional fragment. This will enable the representation of the uncertainty in the course of work and, consequently, will ensure the flexibility in the process models. In this manner, the configurable fragments can be either included-in or excluded-from the process according to the probability of the relevant exceptional situations. Consequently, differently customized process instances can be built. This in turn has enabled to form CRPMs, which contain all known exceptional situations for construction processes, based on the configurable templates. The proposed structure of the CRPM solved the conflict between (1) the assumption that construction processes describe always unique objects and, therefore, these processes should be always designed from scratch in each usage (Egan 1998) and (2) the need to document the process knowledge as a standard reusable construction process. The compromise solution is presented as a standard flexible process representation that is realized in the shape of a CRPM. Accordingly, the relevant CRPMs can be tailored and adapted in each implementation case to suit the boundary conditions of the current situation.

To ensure an effective management of the CRPMs a knowledge-base structure, as an ontology model, was suggested. In view of that, a possible implementation of this knowledge-base, as a data source linked to a management tool for construction processes, was proposed. Within the implementation environment of this management tool all the phases of the CRPM life cycle are supported.

This management tool can be used in the planning phase as well as in the execution phase of the project. In the planning phase this can help (1) to speed up the planning process and (2) to ensure getting more reliable process schedule plans. Also, (3) what-if scenarios can be implemented in the planning phase to study the effect of specific situations without endangering the success of the process objectives. In the execution phase the management tool can help (4) to accelerate the adaptability of the changed schedule plans by offering ready

128 8. CONCLUSIONS AND FUTURE RESEARCH

integrable solutions for recurring problems. Moreover, (5) it enables the enhancement of the CRPM included knowledge according to the evaluation through implementation. This enhancement will ensure that the CRPMs are up-to-date and reliable to use at any time.

The configuration concepts introduced within this research work were developed on the conceptual level of the process and not on the operational level, i.e. they are intended to be used for process modeling and not for workflows. Accordingly, the implementation of these concepts in the management tool was within a scheduling service, which did not apply any workflow technology. Consequently, this service is able to generate process schedules from the respective CRPMs and to compare different change-resulting schedule versions of one process case.

The exceptional events included in each CRPM can be used, in the planning phase of the project as a part of the checklist for risk management. Accordingly, risks can be identified based on the project relevant CRPMs and, subsequently, risk assessment can be carried out. Hence, the risks with probability/impact values above the agreed thresholds should be considered in the planning phase of the project in a proactive way. This means that one of the alternative configurable fragments, which represents a risk treatment fragment, should be adopted (included) as a part of the configured CRPM.

However, as the process is considered separately, i.e. without considering the whole project and environmental dependencies, several detrimental events that have no direct relationship to this specific process cannot be documented on the reference level. For example, only by considering the project spatial dependencies it can be deduced that a brick-work process may be disturbed by ground water risk as this process will take place in the basement of a building, see 7.5. In view of that, a CRPM according to the proposed design of this work cannot cover all the exceptional situations that may affect a process as the real interdependencies go beyond the process itself. As a CRPM cannot cover all the exceptional situations that may affect a process, additional adjustments may be needed in the planning and execution phases. Ad-hoc adjustments to the process model instance may be even needed in the execution time as a response to the new conditions of the implementation case. Neverthe-less, the procedures in the background of the configurable templates can still help to carry out the needed schedule adjustments more quickly than making them manually as usual.

This work showed that it is feasible to engage the business process modeling concepts in the construction sector for the documentation, the communication and the optimization of the process knowledge. Anyway, to realize these CRPMs in the construction practice it is still required from the construction companies to structure their knowledge in a process-oriented way (Rüppel and Lange 2006) and more specifically according to the suggested structure of the CRPM, i.e. essential and exceptional parts etc. For this purpose, only qualified personnel should carry out the modeling of the needed CRPMs. Qualification means here that the modelers should possess enough knowledge concerning the construction process technical issues and the process modeling issues.

The management of CRPMs is separated in this work between the modeler and the planner roles. This is made to show that the planner of the process schedules is not required to have a comprehensive practical and modeling knowledge, while the CRPM modeler should possess

8. CONCLUSIONS AND FUTURE RESEARCH 129

this knowledge. However, a notice should be mentioned here as the planner, who will use the CRPMs developed by the modeler, may depend totally on these CRPMs to develop his schedules. Consequently, this may hinder the creative thinking and the individuality, which are needed from the planner part especially because a CRPM cannot cover all the possible exceptional situations. Therefore, these CRPMs should be dealt with as a soft guide to support the planner and not as a restriction to his individual ideas or as a replacement to his experience.

8.2. OUTLOOK OF THE POSSIBLE FUTURE RESEARCH TOPICS

It was already demonstrated that the developed approach offers different positive scientific and practical aspects that help to improve the current state of process knowledge management in construction. However, due to the size and the complexity of the studied field, there are still some important aspects, which are not considered within the presented work. These aspects were figured out by following the conclusions of this work and based on the results of the case studies in chapter 7. By taking these aspects into account the limitations of the suggested approach can be reduced and a more comprehensive solution, which is in step with the actual practice, can be achieved. These aspects are introduced in the following as possible future topics that can be contemplated as an enhancement or a continuation to this research effort.

8.2.1. CONSIDERATION OF THE PROJECT LEVEL

Each construction project represents several relationships among several processes. The aggregation of the sub-products of these processes builds the whole targeted product of the project. These processes should be linked to each other in a way which considers, amongst others, the project duration, the budget, the technical dependencies, the spatial dependencies among the sub-products and the available resources. The variety of dependencies that influ-ence the project course of processes make it mostly impossible to design a CRPM that describes standard projects. In view of that, a construction project can be considered as unique relationships among several common processes. To design a project schedule starting from the CRPMs an approach is needed to link the configured instantiated CRPMs in a way regards all the dependency types mentioned previously. An approach to form a project schedule start-ing from process schedules is now one of the research topics of the German Research Project “MEFISTO”32 (Scherer 2010).

8.2.2. INTEGRATE CONFIGURABLE RESOURCES IN CRPM

A CRPM includes treatment solutions for recurring risks in the shape of configurable process model fragments. Nevertheless, a treatment of a specific risk must not be necessarily by add-ing or removing some process fragments. For example, changes in the planned allocation of resources may be either needed in parallel to the process changes or even it may be alone sufficient to handle a specific problem without a change in the structure of the process model. The consideration of process resources will demand removing resources conflict by either adding more resources or by shifting the corresponding tasks in a proper way, which means

32 http://www.mefisto-bau.de/

130 8. CONCLUSIONS AND FUTURE RESEARCH

more changes to the process course of work. Actually, resource-based scheduling is an important aspect to consider, as it ensures getting more practical schedule plans. However, the consideration of the resources on the reference level of the processes, i.e. within the CRPMs, will demand to develop configurable resource elements and to establish an approach to integrate them in the CRPMs. This can, in general, enhance the reusability and the compre-hensiveness of the designed CRPMs. Even so, additional adjustments to the configured resources and processes will be needed as the project level of modeling will be considered.

8.2.3. MULTI-CRITERIA DECISION MAKING

As it was shown previously in 4.6, more than one solution may be available for each recurring problem. Moreover, different alternative execution methods can be implemented to build the same product. The right decision between variants in the planning phase of the project plays an essential role to reduce the probability to introduce changes later during the project. As construction processes are influenced by several factors, e.g. duration, cost, error rate etc, it is reasonable to use multi-criteria decision making to take the configuration decisions needed for each CRPM use. Since the values of the decision criteria are not deterministic in nature, e.g. the estimated duration and cost may change by time, a stochastic multi-criteria decision making approach, as a more proper solution, should be developed and integrated within the configuration step of the CRPMs to improve the quality of the configuration decisions.

8.2.4. RIPPLE EFFECT OF CHANGES

The complex dependencies among the project components may require making additional secondary changes as consequences of the main change. These changes may not only be needed within the process where the main change is done but they may also be needed in processes those (1) produce elements that have spatial relationships to the product produced by the under-change process, or (2) those share some resources with the under-change process. Proofing the need for secondary changes should, therefore, consider all different types of dependencies in the project between the processes and between their products.

For instance, the spatial dependencies between the project elements can be inferred from the hierarchical description of the project elements such as by using a deliverable-oriented WBS. A more detailed description of the element dependencies in the project can be obtained from the IFC model, which includes a description of the spatial structure of the product as well.

Generally, the effective identification of the consequences of a change demands that all types of possible project dependencies will be considered. For this purpose, an association approach, which integrates the resource model with the schedule model and the spatial model of the project in one model, can be used. In this way, this multi-aspect model will allow to check resources or spatial conflicts when changes are planned and, consequently, the range and intensity of the ripple effect of the planned changes can be better predicted.

8 . REFERENCES 131

8. REFERENCES

Abecker A., (2004): Business-process oriented knowledge management: concepts, methods, and tools. Forschungszentrum Informatik an der Universität Karlsruhe (FZI). Dissertation: Fakultät für Wirtschaftswissenschaften. Karlsruhe, Germany.

Adam O., Chikova P., Hofer A. and Vanderhaeghen D., (2005): Customer-Driven Process Management in Value-Added Networks Using an Architecture for Collaborative Business. Collaborative Electronic Commerce Technology and Research (CollECTeR) Europe 2005 - Collaborative Business, Furtwangen, Germany.

Ahmed S., Sriram D. and Logcher R., (1992): Transaction-Management Issues in Collaborative Engineering, J. comput. Civ. Eng., ASCE 6 (1)(1992) 85-105.

Alexander C., Ishikawa S., and Silverstein M., (1978): A Pattern Language: Towns, Build-ings, Construction. Oxford University Press.

Alhir S., (1999): UML in a nutshell, a desktop quick reference, O'Reilly publisher, Cambridge.

Ambler S W., (2003): The Elements of UML Style, Cambridge University Press, Cambridge.

ARMIC, ALARM, IRM, (2002): A Risk Management Standard. London: Association of Insurance and Risk Managers, the National Forum for Risk management in the Public Sector (ALARM), Institute of Risk Management (IRM).

URL: ww.theirm.org/publications/documents/Risk_Management_Standard_030820.pdf.

AS/NZS 4360 (2004): The Australian and New Zealand Standard on Risk Management.

BS PD ISO/IEC GUIDE 73 (2002): Risk management. Vocabulary. guidelines for use in standards. British Standards Institution. ISBN: 0580401782

Cardoso J., (2007): Semantic Web Services: Theory, Tools, and Applications. IGI Global Publishing. USA.

Casati F. and Pozzi G., (1999): Modeling Exceptional Behaviors in Commercial Workflow Management Systems. COOPIS „Proceedings of the Fourth IECIS International Conference on Cooperative Information Systems“. IEEE Computer Society publishing. USA.

Cashman P. M. and Preene M., (2002): Groundwater Lowering in Construction: A Practical Guide. Spon Press, USA and Canada.

Chahrour R., (2007): Integration von CAD und Simulation auf Basis von Produktmodellen im Erdbau. Dissertation. Kassel University Press. Germany.

Charoenngam C., Coquince S.T. and hadikusumo B.H.W., (2003): Web-Based Application for Managing Change Orders in Construction Projects. J. Constr. Innov. 3 (2003) pp. 197-215.

Construction and Property Research Centre (CPRC), (2004): Industrial Report “Managing Change in Construction Projects”, university of west of England. PRISTOL, UK.

URL: www.built-environment.uwe.ac.uk/research/cprc/publications /mcd.pdf.

Construction Industry Research and Information Association (CIRIA), (2001): Managing project change; a best practice guide. CIRIA C556, UK.

132 8 . REFERENCES

Construction Owners Association of Alberta (COAA). (2002): Project Rework Reduction Tool (PRRT).

URL: www.coaa.ab.ca/BESTPRACTICES/Rework/ProjectReworkReductionTool/tabid/92/Default.aspx.

Cuntz N. and Kindler E., EPC Tools

URL: http://wwwcs.upb.de/cs/kindler/Forschung/EPCTools/.

Davies J., Fensel D. and van Harmelen F., (2002): Towards the Semantic Web: Ontology-Driven Knowledge Management. John Wiley & Sons Inc. USA.

De Meyer, A., Loch, C.H. and Pich, M.T., (2002): Managing Project Uncertainty: From Variation to Chaos. Sloan Management Review, 43(2): 60-67.

Dellarocas C. and Klein M., (2000): A Knowledge-Based Approach for Handling Exceptions in Business Processes. Information Technology and management 1 (3):155-169.

Dumas M., ter Hofstede A.H.M. and van der Aalst W.M.P., (2005): Process-Aware Information Systems: Bridging People and Software through Process Technology. Wiley & Sons publishing. USA.

Egan, J., (1998): Rethinking Construction, The report of the Construction Task Force on the scope for improving quality and efficiency in UK construction. Department of the Environment, Transport and the Regions, London.

Ekambaram P., Kumaraswamy M.M., Ng T.S.T. and Love P.E.D., (2005): Management of Rework in Hong Kong Construction Projects, In: Sidwell, A.C., Proceedings of the QUT Research Week 2005. Brisbane, Australia, Queensland University of Technology, CD ROM, 6 pages.

Elwert U. and Flassak A., (2008): Nachtragsmanagement in der Baupraxis Grundlagen - Beispiele - Anwendung. Vieweg & Sohn Verlag. Wiesbaden. Germany.

Faschingbauer G., (2010): Simulationsbasierte Systemidentifikation im Rahmen der baubegleitenden geotechnischen Überwachung. Heft 10, Dissertation, Civil Engineering Faculty, Institute for Construction Informatics, TU Dresden, Germany.

Fettke P. and Loos P. (Eds), (2007): Reference Modeling for Business Systems Analysis, Idea Group Publishing.USA.

Fettke P. and Loos P., (2004): Referenzmodelle für den Handel. HMD - Praxis Wirtschaftsin-form. 235.

Forman E. and Selly M. A., (2002): Decision by Objectives. World Scientific Publishing Company.

Fowler M. and Scott K., (1997): UML distilled: Applying the Standard Object Modeling Language, Addison-Wesley, Reading, Mass., USA.

Franz V., (1989): Planung und Steuerung komplexer Bauprozesse durch Simulation mit modifizierten höheren Petri-Netzen,. Dissertation, Gh Kassel.

Frigenti E. and Comninos D., (2002): The practice of project management, a guide to the business-focused approach. Kogan Page Publishing. USA.

8 . REFERENCES 133

Gamma E., Helm R., Johnson R. and Vlissides J., (1995): Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. Boston, USA.

GDCPP (2001): Generic Design and Construction Process Protocol.

URL: www.processprotocol.com

Gehbauer F., Zülch G., Ott M. and Börkircher M., (2007): Simulation-based analysis of disturbances in construction operations. Proceedings of the International Group for Lean Construction fifteenth conference (IGLC-15), Michigan, USA.

Gehre a., Katranuschkov p. and Scherer R. J., (2007): Managing Virtual Organisation Processes by Semantic Web Ontologies, in: Rebolj D. (ed.) „Bringing ITC Knowledge to Work“, Proc. of the 24th CIB-W78 Conference, the 14th EG-ICE Workshop & the 5th ITC@EDU Workshop, Maribor, 26-29 June 2007, ISBN 978-961-248-033-2. pp. 177-182.

Gehre A., Katranuschkov P. and Scherer R.J., (2008): Semantic Support for Construction Process Management in Virtual Organisation Environments. In: ECPPM 2008 - eWork and eBusiness in Architecture, Engineering and Construction. Zarli A. & Scherer R. (Eds.); pp. 85-92; A.A. Balkema.

Gomez-Perez A., Fernandez-Lopez M. and Corcho-Garcia O., (2004): Ontological Engineering: With examples from the areas of Knowledge Management, e-Commerce and the Semantic Web. Springer publishing Berlin.

Hajjar D. and AbouRizk S.M., (1998): A framework for applying simulation in construction. Canadian journal of civil engineering, Ottawa, 25(3): 604-17, Canada.

Halpin D. W. and Martinez L. H., (1999): Real world application of construction process simulation. Proceeding of the 1999 winter simulation conference, 956-962.

Halpin D. W., (1977): CYCLONE- method for modeling job site processes. Journal of the construction division, September, 489-99.

Hao Q., Shen W., Neelamkavil J. and Thomas R., (2008): Change Management in Construction Projects. In: Proc. 25th W78 Conf., Improving the Management of Construction projects Through IT Adoption; Leonardo Rischmoller (ed). Santiago, Chile.

Havey, M., (2005): Essential Business Process Modeling, O'Reilly Media publishing. USA

Hegazy T., Zaneldin E. and Grierson D., (2001): Improving Design Coordination for Building Projects: I. Information Model, J. Constr. Eng. Manag., ASCE 127 (4) (2001) pp. 322-329.

Heisig P., (2001): Business Process Oriented Knowledge Management –Methode zur Verknüpfung von Wissensmanagement und Geschäftsprozessgestaltung. 1. Konferenz Professionelles Wissensmanagement - WM 2001. Baden-Baden, Germany.

Hepp M., De Leenheer P. and de Moor A. (Editors), (2007): Ontology Management Semantic Web, Semantic Web Services, and Business Applications (Semantic Web and Beyond), Springer Publishing.

Hohmann D., (1971) Technologische Grundmodelle, ein Beitrag zur Rationalisierung der technologischen Vorbereitung, Dissertation, die Deutschen Bauakademie zu Berlin.

134 8 . REFERENCES

Hohpe G. and Woolf B., (2004): Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. USA.

Holz K P., Schley F., Savidis S. and Mejstrik M., (2007): Berücksichtigung von Ausnahme-fällen bei der kooperativen Bearbeitung von Projekten des konstruktion Tiefbaus. In Rüppel U. (ed.): Vernetzt-kooperative Planungsprozesse im Konstruktiven Ingenieur-bau: Grundlagen, Methoden, Anwendungen Und Perspektiven Zur Vernetzten Ingeni-eurkooperation. Springer publisher, Berlin, Germany.

Huhnt W. and Enge F., (2006): Can algorithms support the specification of construction schedules?, ITcon Vol. 11, Special Issue Process Modelling, Process Management and Collaboration , pg. 547-564,

URL: http://www.itcon.org/2006/39

Ibbs C. W., Wong C.K. and Kwak Y.H., (2001): Project Change Management System, J. Manage. Eng. ASCE 17(3) pp 159-165.

Issa A. R. and Cox, F. R., (1996): Using process modeling to gain ISO 9000 certification in construction. Conf. Proc. 1996 Computing in Civil Engineering, Anaheim, Calif., 1013–1019.

Issac S., and Navon R., (2008): Feasibility Study of an Automated Tool for Identifying the Implication of Changes in Construction Projects. Journal of Construction Engineering and Management, 134(2)139-145.

Jungnickel D., (2008): Graphs, Networks & Algorithms, Springer Berlin Heidelberg New York.

Kahraman G. (editor), (2008): Fuzzy Multi-Criteria Decision Making Theory and Applications with Recent Developments. Springer Science+Business Media, LLC.

Kammer P., Alan Bolcer G., Taylor R. and Bergman M., (2000): Techniques for Supporting Dynamic and Adaptive Workflow, in : Computer Supported Cooperative Work, Volume 9, Issue 3-4 (August 2000), Pages: 269 – 292. Kluwer Academic Publishers. USA.

Kantelberg A., (1998): Stochastische Petri-Netze Anwendung aus dem Bereich der Bauatellenlogistik am Beispiel des Vorhabens Potsdamer Platz Berlin. „9.Treffen der Arbeitsgruppe: Petrinetze und Informationssysteme in der Praxis, Kassel.

Karim A. and Adeli H., (1999): CONSCOM. An oo Construction Scheduling and Change Management System. Journal of Construction Engineering and Management, ASCE 125 5 (1999), pp. 368–376

Katranuschkov P., Gehre A. and Scherer R. J., (2007): Reusable Process Patterns for Collaborative Work Environments in AEC, in: Pawar K. W., Thoben K.-D. & Pallot M. (eds) “ICE 2007 – Proceedings of the 13th International Conference on Concurrent Enterprising”, Sophia Antipolis, 4-6 June 2007, publ. by Centre of Concurrent Enterprising, Nottingham, UK, ISBN 978-085-358-233-5, pp. 87-96

Keller G., Nüttgens M. and Scheer A.-W., (1991): Semantische Prozessmodellierung auf der Grundlage „ Ereignisgesteuerte Prozessketten (EPK). Veröffentlichung des Instituts für Wirtschaftsinformatik, Paper 089, Saarbrücken.

URL: http://www.iwi.uni-sb.de/Download/iwihefte/heft89.pdf.

8 . REFERENCES 135

Keller M., (2006): Unterstützung Unternehmensübergreifender Kooperation in Bauprojekten - Modelle, Methoden und Prozesse. Heft 6, Dissertation, Civil Engineering Faculty, Institute for Construction Informatics, TU Dresden, Germany.

Kendrick T., (2003): Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project. AMACOM “American Management Association”. USA.

Khneisseh A., (2005): Geschäftsprozessmodellierung mit Petri-Netzen. Dissertation, Civil Engineering Faculty, TU Dresden. Expert-Verlag. Germany.

Klauer T., (2005). Eine prozessorientierte Kooperationsplattform für Bauprojekte auf Basis eines internetbasierten Workflow-Managements. Dissertation. Darmstadt University of Technology. Germany.

Klein M., Dellarocas C. and Bernstein A. (Eds.), (2000): Adaptive Workflow Systems (spe-cial issue), Journal of Computer Supported Cooperative Work 9 (3– 4).

König M. and Tauscher E., (2006): Berechnung von Bauabläufen mit verschiedenen Zusführungsvarianten; International Conference on the Applications of Computer Science and Mathematics in Architecture and Civil Engineering (IKM), Weimar

Krömker M.F., Weber V., Steinlechner V. and Wämke P., (1998): A reference model and software support for bid preparation in supply chains in the construction industry, in: R.R. Wagner, A.M. Tjoa (Eds.), Proceedings of Ninth International Workshop on Data-base and Expert Systems Applications, DEXA’98, IEEE Computer Society, Vienna, Austria.

Leach P. L., (2005): Critical Chain Project Management, second edition. Artech House, Inc. Norwood, MA, USA.

Lee S. H., (2006): Dynamic Planning and Control Methodology: Understanding and Manag-ing Iterative Error and Change Cycles in Large-Scale Concurrent Design and Construc-tion Projects. Thesis (Ph.D.) Massachusetts Institute of Technology, Dept. of Civil and Environmental Engineering. Boston, MA, USA.

Lee S., Peña-Mora F. and Park M., (2006): Web-enabled System Dynamics Model for Error and Change Management on Concurrent Design and Construction Projects, ASCE, Journal of Computing in Civil Engineering, Reston, VA, Vol. 20, No. 4, July-August 2006, pp. 290-300.

Loosemore M., Raftery J., Reilly C. and Higgon D., (2006): Risk Management in Projects, Taylor & Francis Group, London & New York.

Lootsma F., A.,(1999): Multi-Criteria Decision Analysis via Ratio and Difference Judgement. Delft University of Technology, the Netherlands.

Love P.E.D., Wyatt A.D. and Mohamed S., (1997): Understanding Rework in Construction. Construction Process Re-engineering. S. Mohamed, Ed., Griffith University, Gold Coast, Australia, 14-15(July): 269-278.

Lui L.Y. and Ioannou P.G., (1992): Graphical Object-Oriented Simulation System for Con-struction Process Modeling. Proceeding of the eighth conference on computing in civil engineering, ASCE, USA.

136 8 . REFERENCES

Luo Z., Sheth A., Kochut K. and Miller J., (2000): Exception Handling in Workflow Sys-tems. Applied Intelligence. Volume 13 , Issue 2 (September-October 2000). Pages: 125 – 147.

Marshall C., (2000): Enterprise Modelling with UML-designing Successful Software through Business Analysis, Addison-Wesley Professional, Reading, Mass.

Mayer R. J., Cullinane T. P., deWine P. S., Knappenberger W. B., Perakath B., and Wells M.S., (1992): Information Integration for Concurrent Engineering (IICE), IDEF3 Process Description Capture Method Report, Air Force Systems Command, Wright- Patterson Air Force Base, Ohio 45433, AL-TR-1992-0057.

Mendling J. and Nüttgens M., (2005): EPC Markup Language (EPML) - An XML-Based Interchange Format for Event-Driven Process Chains (EPC). Technical Report JM-2005-03-10. Vienna University of Economics and Business Administration.

Mendling J., (2008): METRICS FOR PROCESS MODELS; Empirical Foundations of Verification, Error Prediction, and Guidelines for Correctness. Lecture Notes in Busi-ness Information Processing. Springer publishing. Berlin, Germany.

Mendling J., Neumann G. and Nüttgens M. (2005): Towards Workflow Pattern Support of Event-Driven Process Chains (EPC). In: XML4BPM 2005 “XML Interchange Formats for Business Process Management”, Nüttgens M., Mendling J. (eds.) 2nd Workshop of German Informatics Society e.V. (GI) in conjunction with the 11th GI Conference “BTW 2005”. Karlsruhe, Germany.

Mokhtar A., Bedard C. and Fazio P., (1998): Information Model for Managing Design Changes in a Collaborative Environment, j. Comput. Civ. Eng., ASCE 12(2) (1998) 82-92.

Motawa I., Anumba, C., Lee, S. and Peña-Mora, F., (2007): An Integrated System for Change Management System in Construction, Automation in Construction, Elsevier, Oxford, UK, Vol. 16, No. 3, May 2007, pp. 368-377.

Muehlen M.z., (2004): Workflow-based Process Controlling. Foundation, Design, and Implementation of Workflow-driven Process Information Systems. Advances in Information Systems and Management Science, vol. 6. Logos, Berlin.

Nastansky L. and Hilpert W., (1994): The GroupFlow System: A Scalable Approach to Workflow Management between Cooperation and Automation, in: Wolfinger, Bernd (Ed.): Innovationen bei Rechen- und Kommunikationssystemen- Eine Herausforderung an die Informatik, Proceedings of 24th Annual Conference of the German Computer Society during 13th World Computer Congress, IFIP '94, Springer Verlag 1994.

Nilson A. H., Darwin D. and Dolan C. W., (2003): Design of Concrete Structures. McGraw-Hill Education Pvt Ltd, 13 edition.

OASIS (2007): Web Services Business Process Execution Language Version 2.0. OASIS Web Services Business Process Execution Language (WSBPEL) Technical Committee. 11 April 2007.

URL: http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

OMG (2008): Business Process Modeling Notation Specification, Version 1.1, February 2008.

8 . REFERENCES 137

URL: http://www.bpmn.org/

Pallas Athena (2000): Case Handling with FLOWer: Beyond Workflow. Internal report, Pallas Athena, Apeldoorn, The Netherlands.

Park, M., (2002): Dynamic Change Management for Fast-Tracking Construction Projects. The 19th International Symposium on Automation and Robotics in Construction, Wash-ington DC, USA.

Peltonen H., Mannisto T., Alho k., and Sulonen R., (1993): An Engineering Document Management System, Proc. ASME Winter Annu. Meeting.

Petri C. A., (1962): Kommunikation mit Automaten, Schriften des Rheinsch-Westfälischen Instituts für instrumentelle Mathematik, Nr.2. Bonn, Germany.

Probst G., Raub S. and Romhardt K. (2006): Wissen managen: wie Unternehmen ihre wertvollste Ressource optimal nutzen. Gabler Verlag. 2006. ISBN 3834901172.

Project Management Institute (PMI) (2006): Practice Standard for Work Breakdown Structures, ISBN: 1-933890-13-4, Second Edition.

Project Management Institute (PMI), PMBOK Guide (2004): A Guide to the Project Management Body of Knowledge, Pennsylvania, USA.

Recker J., Rosemann M., van der Aalst W.M.P. and Mendling J., (2006): On the Syntax of Reference Model Configuration: Transforming the C-EPC into Lawful EPC Models. In C. Bussler et al. (eds.), BPM 2005 Workshops (Workshop on Business Process Reference Models), volume 3812 of Lecture Notes in Computer Science, pp. 497-511. Springer-Verlag, Berlin.

Rosemann M. and van der Aalst W.M.P., (2003): A Configurable Reference Modeling Language. QUT Technical report, FIT-TR-2003-05, Queensland University of Technology, Brisbane.

Rüppel U. and Klauer T.,(2004): Internet-based Workflow-Management for Civil Engineering Projects. In: Proceedings of the 10th International Conference on Computing in Civil & Building Engineering, Paper 159, Weimar, 2004 (ISBN 3-86068-213-X).

Rüppel U. and Lange M., (2006): Network-based Agent- and Process Modelling-Methods for Cooperation Support in Civil Engineering Applications on Example of Fire Protection Engineering. In: Electronic Journal of Information Technology in Construction.

Rumbaugh J., Jacobson I. and Booch G., (2004): The Unified Modeling Language Reference Manual. Addison-Wesley Longman, Amsterdam.

Russell N., (2007): Foundations of Process-Aware Information Systems. Dissertation: URL: http://www.yawlfoundation.org/documents/RussellThesisFinal.pdf.

Russell N., ter Hofstede A.H.M., Edmond D. and van der Aalst W.M.P., (2004): Workflow Data Patterns. QUT Technical report FIT-TR-2004-01, Queensland University of Technology. Brisbane, Australia.

Sawhney A. Abudayyeh O. and Chaitavatputtipom T., (1999): Modeling and Analysis of a Concrete Production Plant Using Petri Nets. In: Journal of Computing in civil Engi-neering and Management, New York, USA.

Sawhney A. and AbouRizk S.M., (1996): Computerized tool for hierarchical simulation modeling. Journal of computing in civil engineering, ASCE. April, 115-24.

138 8 . REFERENCES

Scheer, A.-W., (1999): ARIS-Business Process Framework. Springer Publishing, Berlin, Germany.

Scheer, A.-W., (2000): ARIS-Business Process Modeling. Springer Publishing, Berlin, Germany.

Scherer R., (2006): Integrierte dynamische Produkt- und Prozessmodellierung mit dem Ziel der Risikobewertung von Bauprojekten, in: Wenzel S. (ed.) Simulation in Produktion und Logistik 2006, 12. ASIM Fachtagung, Kassel, Germany, Sept. 25-27, 2006, SCS Publishing House e.V., San Diego-Erlangen, ISBN 3-936150-48-6.

Scherer R., (2010): Mefisto-Partnerschaftliche Nutzung von Multi-Modellinformationen zur Steuerung, Simulation und Führung von Bauprojekten. In MEFISTO: Management – Führung – Information – Simulation im Bauwesen. Veranstaltungen des Instituts für Bauinformatik, Heft 2, ISBN 978-3-86780-187-4. Mefisto Kongress 2010.

Schröder T., Savidis S., and Holz, K.-P., (2007): Praxiseinsatz einer Internetbasierten Infor-mationsplattform für die Bauausführung im Spezialtiefbau. Veröffentlichungen des Grundbauinstitutes der Technischen Universität Berlin, Heft Nr. 41, (S. 49-61). Berlin.

Sharifi R., Baciu S. and Zayed T., (2006): Simulation of QA/QC impact on onshore jackets fabrication productivity. Proceedings of the joint international conference on computing and decision making in civil and building engineering- Building on IT, Montreal Canda.

Sharmak W. and Scherer R.J., (2009): Adaptable Project Schedule Plans Using Change Templates. In: Proc. 18th IKM Conf., International Conference on the Application of Computer Science and Mathematics in Architecture and Civil Engineering; K. Gürlebeck and C. Könke (eds.), Weimar, Germany

Sharmak W., Scherer R. J. and Katranuschkov P., (2007): Configurable Knowledge-Based Risk Management Process Model within the General Construction Project Process Model, in: Rebolj D. (ed.) „Bringing ITC Knowledge to Work“, Proc. of the 24th CIB-W78 Conference, the 14th EG-ICE Workshop & the 5th ITC@EDU Workshop, Maribor, 26-29 June 2007, ISBN 978-961-248-033-2. pp. 301-308.

Spooner D. and Hardwick M, (1993): Using Persistent Object Technology to Support Concurrent Engineering Systems, Concurrent Engineering: Methodology and Applications, Elsevier Science, Amsterdam, 1993, pp. 205-234.

Sun, M., Senaratne, S. Fleming, A., Motowa, I. and Lin Yeoh, M., (2006): A change management toolkit for construction projects, Architectural Engineering and Design Management, University of the west of England, University Press/Springer-Verlag, UK.

Tommelein I.D., Carr R.I. and Odeh A.M., (1994): Knowledge Based Simulation of Construction Plans. Proceedings of the winter simulation conference.

Uher E. T., (2003): Programming and Scheduling Techniques, UNSW press, Australia.

Van der Aalst W. M. P and ter Hofstede A., (2005): YAWL: Yet Another Workflow Lan-guage. Information Systems, 30(4):245–275.

URL: http://www.yawl-system.com/resources/patterns.html

Van der Aalst W. M. P., Scoffele, M. and Wamelink, J. W. F., (2003): Case Handling in Construction. Autom. Constr., 12(3), 303–320.

8 . REFERENCES 139

Van der Aalst W. M. P., ter Hofstede A. H. M, Kiepuszewski B. and Barros A. P., (2003): Workflow Patterns. Technical report. Distributed and Parallel Databases. Eindhoven University of Technology, Eindhoven.

URL: http://www.workflowpatterns.com/

Van der Aalst W. and van Hee K., (2002): Workflow Management: Models, Methods, and Systems (Cooperative Information Systems), the MIT Press Cambridge, England.

Wamelink J.W.F., Stoffele M. van der Aalst and W.M.P., (2002): Workflow management in construction: opportunities for the future, in: K. Agger, P. Christiansson, R. Howard (Eds.), Proceedings of CIB W78 Conference 2002: Distributing Knowledge in Building, Aarhus, Denmark, International Council for Research and Innovation in Building and Construction, Rotterdam, The Netherlands, pp. 115– 122.

Wand Y. and Weber R., (2002): Research Commentary: Information Systems and Conceptual Modeling - A Research Agenda. Information Systems Research 13(4).

Wasserfuhr R. and Scherer R. J., (1999): ToCEE-Process and Information Logistics services: Documentation of the Server and Tools, EU/CEC ESPRIT Project 20587, Report E4, Inst. Of Applied Computer Science in Civil Engineering, TU Dresden, Germany.

Weske M., (2007): Business Process Management Concepts, Languages, Architectures, Springer Publishing. Verlag Berlin Heidelberg. Germany.

WFMC (2010): XPDL Support and Resources.

URL: http://www.wfmc.org/xpdl.html

Wideman Max R.(Ed.),(1992): Project and Program Risk Management: A Guide to Managing Project Risks and Opportunities. Project Management Institute (PMI). USA.

Ziemann J. and Mendling J., (2005): EPC-Based Modelling of BPEL Processes: a Pragmatic Transformation Approach. In Proceedings of the 7th International Conference "Modern Information Technology in the Innovation Processes of the Industrial Enterprises" (MITIP 2005), Genova, Italy.

Zülch G. and Börkircher M., (2006): Modellierung und Simulation von Bauprozessen: Planungsunterstützung im Baubetrieb unter Berücksichtigung von Bauablaufstörungen. In: Simulation in Produktion und Logistik 2006.Hrsg.: Wenzel, Sigrid.San Diego, Erlangen: SCS Publishing House, 2006, S. 561-570.

Bisher erschienene Dissertationen, Habilitationen und Hefte des Instituts für Bauinformatik*

Christoph Meinecke

Ein objektorientiertes Konstruktionsexpertensystem mit Regelmethoden

Selbstverlag Karlsruhe, 7/1995

Markus Hauser

Eine kognitive Architektur für die wissensbasierte Unterstützung der frühen Phasen des Entwurfs von Tragwerken

logos Verlag Berlin, 06/1998

Martin Zsohar

Stochastische Größen der Resonanzfrequenzen und der Verstärkung seismischer Wellen im horizontal geschichteten zufälligen Medium

Shaker Verlag Aachen, 07/1998

Christian Steurer

Modellierung und Berechnung des Ermüdungsriß-fortschritts mit stochastischen Differential-gleichungen

Selbstverlag, 02/1999

Peter Katranuschkov

A Mapping Language for Concurrent Engineering Processes

Heft 1, 02/2001

Karsten Menzel

Methodik zur nachhaltigen, rechnergestützten Ressourcenverwaltung im Bauwesen

Heft 2, 11/2003

Michael Eisfeld

Assistance in Conceptual Design of Concrete Structures by a Description Logic Planner

Heft 3, 11/2004

Matthias Weise

Ein Ansatz zur Abbildung von Änderungen in der modellbasierten Objektplanung

Heft 4, 11/2006

Jörg Bretschneider

Ein wellenbasiertes stochastisches Modell zur Vorhersage der Erdbebenlast

Heft 5, 12/2006

Martin Keller

Informationstechnisch unterstützte Kooperation bei Bauprojekten

Heft 6, 06/2007

Kamil Umut Gökce

IT Supported Construction Management Heft 7, 06/2008

Gerald Faschingbauer

Simulationsbasierte Systemidentifikation im Rahmen der baubegleitenden geotechnischen Überwachung

Heft 8, 01/2011

* Bis September 2003 Lehrstuhl für Computeranwendung im Bauwesen