International Construction Specialty Conference of the Canadian Society for Civil Engineering (ICSC) (5th : 2015)

Implementation of construction industry best practices into workflow management systems Golzarpoor, Behrooz; Haas, Carl T. Jun 30, 2015

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
52660-Golzarpoor_B_et_al_ICSC15_260_Implementation_Of_Construction.pdf [ 1.97MB ]
52660-Golzarpoor_B_et_al_ICSC15_260_Implementation_Of_Construction_slides.pdf [ 1006.69kB ]
Metadata
JSON: 52660-1.0076444.json
JSON-LD: 52660-1.0076444-ld.json
RDF/XML (Pretty): 52660-1.0076444-rdf.xml
RDF/JSON: 52660-1.0076444-rdf.json
Turtle: 52660-1.0076444-turtle.txt
N-Triples: 52660-1.0076444-rdf-ntriples.txt
Original Record: 52660-1.0076444-source.json
Full Text
52660-1.0076444-fulltext.txt
Citation
52660-1.0076444.ris

Full Text

5th International/11th Construction Specialty Conference 5e International/11e Conférence spécialisée sur la construction    Vancouver, British Columbia June 8 to June 10, 2015 / 8 juin au 10 juin 2015   IMPLEMENTATION OF CONSTRUCTION INDUSTRY BEST PRACTICES  INTO WORKFLOW MANAGEMENT SYSTEMS Behrooz Golzarpoor1,2, Carl T. Haas1 1 Civil and Environmental Engineering Department, University of Waterloo, Waterloo, ON, Canada 2 bgolzarpoor@uwaterloo.ca Abstract: Several research studies have confirmed that identification and adoption of industry best practices drive performance improvements in terms of cost, schedule, and productivity. Best practices specifications facilitate the reuse of experience within a domain. However, they typically offer abstract suggestions and recommendations that include not only explicit, but also tacit knowledge. Key approaches of adopting and promoting best practices include socialization and face to face interactions, such as meetings, workshops, and training. These approaches, however, are not easily scalable to large capital projects, to provide systematic and consistent adoption of best practices throughout different phases of a project or among different projects. An alternative solution is to transform best practices into processes implementable into workflow management systems. In this paper, well-known best practices in the domain of the construction industry and their common characteristics are investigated. A framework is then established for transforming best practices into structured processes implementable into workflow management systems. Only parts of a best practice can be transformed into a structured process. The proposed framework describes which components of a best practice are more suitable for this transformation. The result is a process with the essence of a best practice that can be embedded into and automated through workflow management systems. This approach of integrating construction industry best practices into workflow management systems, not only facilitates consistent implementation of best practices throughout the project lifecycle and within projects, but also improves conformance to those practices, with the end result of improved capital project performance. 1 INTRODUCTION It is well established from statistical analysis of several projects that effective implementation of best practices and integration of information technologies are correlated with substantial improvements in project performance (Figure 1 & Figure 2). Research studies state that systematic implementation of best practices is one of the most important contributing factors to mega projects’ success (Chanmeka et al. 2012). A best practice might be a single procedure or method, but most usually it is a combination of several policies, rules, procedures, and methods, in a particular domain.     260-1 capital projects. An alternative solution is to transform best practices into workflow processes implementable into Electronic Product and Process Management (EPPM) systems – a type of workflow management system particularly being used for managing mega capital projects. This approach utilizes business process models and workflow engines to facilitate more consistent implementation of best practices throughout different phases of a project or among different projects. Fundamental improvements in communication and collaboration technologies and the increased use of EPPM systems – that are process-based and workflow-driven – in managing mega capital projects provided the required infrastructure, and facilitate putting this approach into practice. Utilization of EPPM systems and workflow engines offer the advantages of consistency, accuracy, and scalability, and thus can be considered a key tool for adopting best practices in mega capital projects. 2 BACKGROUND Mega construction projects typically involve many stakeholders from different parts of the world, with diverse organizational structures and cultures, and with distinct specialized expertise. A typical oil and gas project is comprised of a few owners, tens of general contractors, and hundreds of sub-contractors from different firms and disciplines, such as engineering, consulting, construction, and facility management; nevertheless, all striving towards the common goal of completing the project. This level of cooperation is made possible in part by advancements in communication and collaboration systems in the domain of information technology. This includes essential communication infrastructure provided by the World Wide Web, database management systems, and real-time data exchange services. Furthermore, such multilateral accomplishments have been aided by substantial improvements in systems tailored to projects and corporations. Examples include advanced project management tools, enterprise resource planning (ERP) (Chung, Skibniewski, and Kwak 2009; Ghosh et al. 2011; O’Connor and Dodd 2000), workflow engines (Tang and Akinci 2012; Cardoso, Bostrom, and Sheth 2004), electronic document management systems (Al Qady and Kandil 2013), knowledge-based information systems (El-Gohary and El-Diraby 2010; Kang, O’Brien, and O’Connor 2012), and more specifically electronic product and process management (EPPM) systems (Shahi et al. 2014). Electronic Product and Process Management (EPPM) Systems are the new technology trend for management of mega capital projects. Their core components are typically a combination of a workflow management system (WfMS), a document management system (DMS), and a collaboration management system. A workflow engine at the heart of the workflow management system facilitates enactment of workflow processes; a document management system supports several types of files and enables sharing and modifying various types of documents. The collaboration management system enables project delivery by collaboration among several stakeholders. The services that EPPM systems offer encompasses planning, coordination, and management activities within the product and project lifecycle. EPPM systems store and retrieve various types of information regarding the lifecycle of a project, and can be used to mine repositories to capture hidden knowledge, and analyze the acquired knowledge for more informed decision making. This knowledge is typically represented in the form of status and progress reports, lessons learned, cost and performance analysis, etc. through dashboards. Implementation of best practices into EPPM systems involves transforming practices into workflow processes. Thus, distinguishing the differences between practice, process, and workflow is vital. Before establishing a framework for practice to process transformation, this paper discusses these differences. 2.1 Process vs. Practice A process is a series of well-defined inter-related steps which delivers repeatable, predictable results. Key features of a process include 1) predictable and definable inputs, 2) linear, logical sequence, 3) clearly definable set of activities, and 4) predictable, desired outcome (Lee 2005). An activity is typically considered as a major unit of work comprising more detailed steps called sub-activities. Whenever an activity is considered as the smallest unit of work, it is called a task. A process is typically used in routine 260-3 circumstances in which repeatable, predictable results are required. Each necessary step is codified in detail and there is no spontaneous decision making involved. A process can be performed manually or can be automated through an information system. For an automated process, the inputs, outputs, and steps involved should be clearly defined; and to implement a process in a workflow management system it should be defined in a standard process modeling language. Typically, automated processes include both automated and manual activities. Request for Information (RFI) and Change Request (CR) processes are examples of such processes. Processes in which all of their activities are automated are called fully automated processes, such as the buying processes in Amazon or eBay. A practice, on the other hand, is a frequently repeated act, habit, or custom that needs a recognized level of skill to be performed. It is an un-codified knowledge that results from human experience and improvisation (Lee 2005). While a practice is still a series of steps, the steps are loosely defined, and the details of how to perform each step is left to the experts who perform them based on their knowledge, experience, skill, and judgment. Practices, thus, are more suitable for dealing with uncertain situations with uncommon or unique results (“IT Catalysts” 2013). Table 2 summarizes key differentiators of processes and practices. Table 2: Process vs. Practice Process Practice  Series of well-defined steps    Deliver repeatable, predictable results   Well-suited to mass production    Includes clear steps and details for tasks  Series of steps, but loosely defined  The specifics are left to the experts performing them  Appropriate for dealing with uncertain situations with unique results   Not necessarily have a clear sequence and details for tasks 2.2 Process Modeling Tools and Standards To implement a process in a workflow management system, it should be defined as a process model using a standard process modeling notation. Several process modeling languages and standards have been developed for modeling business processes. Process modeling can be performed either by representing a process using graphical notations or by representing the semantics of the process using modeling languages. Using graphical notations is more convenient for communication, reengineering, and improvement of processes. Recent modeling tools such as XPDL and BPMN support both a graphical notation and a modeling language. A classification of the most popular modeling tools and standards is presented in Table 3. Table 3: Process Modeling Tools and Standards Classical More Formal Most Recent Flowchart 1920s Functional Flow Block Diagram (FFBD) 1950s Data Flow Diagram (DFD) 1970s ICAM DEFinition (IDEF0) 1970s Petri nets 1960s Workflow patterns YAWL Graph-Based Workflow Language UML 1997 XPDL 2002 BPEL 2004 BPMN 2004 Business Process Modeling and Notation (BPMN) is the most promising process modeling standard. It has been designed by the Object Management Group (OMG) with the aim of identifying best practices of existing modeling tools and combining them into a widely accepted, easy to use language. The same process model in BPMN may encompass different levels of details, each useful for a particular group of 260-4 stakeholders, from business administration people to business analysts and software developers. BPMN defines three levels of process modeling conformance. ‘Descriptive level’, useful in high-level modeling, only includes visible elements and attributes; ‘analytic level’ includes descriptive and a minimal subset of supporting process attributes; and ‘common executable’ offers the elements required for execution of process models. In this paper we use BPMN 2.0 notation for representing sample process models. 2.3 Workflow vs. Process Workflow and process are similar terms and, in certain situations, might be used interchangeably. However, workflow implies a more specific concept than process. While any group of well-defined interconnected steps with an expected result can be called a process, in a workflow the focus is on the piece of work or information that is being passed through initiation to completion. Therefore, a workflow associated with a particular process might not be involved with all the details that are important for completion of the process, such as recording to a database or calling a web-service, but is more dedicated to the flow of work through all the steps. A workflow thus can be defined as an outline or blueprint of a process. A summary of process and workflow differences are presented in Table 4. Table 4: Process vs. Workflow Process Workflow  A process is a series of well-defined inter-related steps  A process is modeled using modeling tools and implemented by coding the steps  A process can be modeled with different abstraction levels: organizational, operational, and implementation levels  The focus is on steps of work  A programmer typically implements a process  A workflow is considered as an outline of a process  The flow of work in a workflow can be updated without changing underlying code  The focus is on organizational details, but can include operational and  implementation-level details  The focus is on the flow of work  A analyst typically can modify the steps and update the flow of a workflow 2.4 Workflow Management Systems (WfMS) Workflow management and workflow specification are concepts tightly related to business process management and process modelling; however, their approach is rather different. Workflow management involves the automation of processes which are comprised of human and machine-based activities (Hollingsworth 1995) and focuses on the flow of information or work among participants. A workflow specification is an abstraction of a process that might not be concerned with all the details of a task, but in any case it is concerned with the inter-relationship, the inputs and outputs, and the externally visible behavior of tasks (Krishnakumar and Sheth 1995).  Automation of business processes partly relies on the coding of software developers for embedding business processes into information systems. Originally, any modification to the process logic, the sequence of activities, and the execution constraints of a process was affecting the programming code and required software developer’s attention. The introduction of object-oriented programming concepts facilitated the separation of process logic modifications from the programming code, and led to the emergence of workflow driven systems. In a workflow management system, features of an application, or tasks of a process, are defined as steps in a workflow, and therefore, the behavior of the system can be modified through changing the steps without any modification to the programming code. Workflow technology, thus, provides separation of business process logic from IT operational support (Hollingsworth 1995).  260-5 A workflow engine is responsible for managing and enacting tasks within workflow specifications according to their execution constraints and organizational predefined rules. The execution constraints of a process are typically defined as properties or attributes of tasks in the workflow specification. The Workflow Reference Model (Hollingsworth 1995), developed by the Workflow Management Coalition (WfMC) is a key reference for workflow management systems and their interfaces. Workflow management systems facilitate more convenient design and implementation of processes with less involvement in programming details. 3 PROPOSED FRAMEWORKS A best practice is a guideline to an improved way of organizing and performing a work. The steps offered in a best practice does not necessarily include well-defined sequence and details, and thus it typically relies on the skills and experience of the actor to fill the gaps, whereas in a structured process the sequence of activities and their execution constraints are completely defined. This paper proposes two frameworks for transformation of best practices into structured processes suitable for implementation via workflow management systems. The frameworks explain how the inherent knowledge of a best practice can be combined with the key characteristics of a structured process, such as well-defined steps, sequence, and execution constraints. In addition, the frameworks clarify how the components of a best practice can be associated with elements of a structured process. 3.1 A Conceptual Framework A practice as a form of knowledge includes explicit, tacit, and implicit types of knowledge (Anand and Singh 2011; Faust 2007). The explicit is the category of knowledge that can easily be identified, codified, stored, and retrieved, and thus, its implementation and automation is relatively straightforward. Interrelated components of a best practice comprising explicit knowledge can be defined as a high level organizational process. Tacit knowledge is inherent with the skills and experience of people, and is hard to capture and codify, and thus, cannot easily be automated. Tacit knowledge or judgmental steps in a practice can be embedded into manual human-tasks of a process. A fraction of tacit knowledge, that is hard but possible to capture and make explicit, is called implicit knowledge. Implicit knowledge is associated with how a process is defined and how it is implemented. It affects the way a process behaves. Table 5: Types of Knowledge in a Practice and their Association with a Process Practice Components … Association with … Process Elements Explicit Knowledge Tacit Knowledge Implicit Knowledge … What is done … … Who accomplish … … How is defined … Structure of the Process Human-tasks of the Process Behavior of the Process Accordingly, we can associate elements of a process with components of a practice. The structure of the process – which defines what is performed – can be defined based on the explicit knowledge present in the practice. The human-tasks of the process – which is related to who has the capability of performing the task – are associated with the tacit knowledge of the practice. The behavior of the process – which is consistent with how the process is defined – signifies the implicit knowledge of the practice (Table 5). 3.2 A Practical Framework The practical framework for transformation of a best practice into a process involves two main steps: (1) identify the related components of a best practice and define them as one or more high-level organizational processes, and (2) transform the organizational processes into well-defined structured processes suitable for implementation via workflow management systems. These steps are presented in Figure 3 and are discussed with examples in the following sections.  260-6 Acknowledgements This research is funded by the Natural Sciences and Engineering Research Council of Canada (NSERC) and Coreworx Inc. Their support is gratefully acknowledged. References Al Qady, M., and A. Kandil. 2013. “Document Discourse for Managing Construction Project Documents.” Journal of Computing in Civil Engineering 27 (5): 466–75. doi:10.1061/(ASCE)CP.1943-5487.0000201. Anand, P., and M. D. Singh. 2011. “Understanding the Knowledge Management.” International Journal of Engineering Science and Technology 3 (2): 926–39. Cardoso, Jorge, Robert P. Bostrom, and Amit Sheth. 2004. “Workflow Management Systems and ERP Systems: Differences, Commonalities, and Applications.” Information Technology and Management 5 (3-4): 319–38. doi:10.1023/B:ITEM.0000031584.14039.99. Chanmeka, Arpamart, Stephen R. Thomas, Carlos H. Caldas, and Stephen P. Mulva. 2012. “Assessing Key Factors Impacting the Performance and Productivity of Oil and Gas Projects in Alberta.” Canadian Journal of Civil Engineering 39 (3): 259–70. doi:10.1139/l11-128. Chung, B., M.J. Skibniewski, and Y.H. Kwak. 2009. “Developing ERP Systems Success Model for the Construction Industry.” Journal of Construction Engineering and Management 135 (3): 207–16. doi:10.1061/(ASCE)0733-9364(2009)135:3(207). El-Gohary, N., and T. El-Diraby. 2010. “Dynamic Knowledge-Based Process Integration Portal for Collaborative Construction.” Journal of Construction Engineering and Management 136 (3): 316–28. doi:10.1061/(ASCE)CO.1943-7862.0000147. Faust, B. 2007. “Implementation of Tacit Knowledge Preservation and Transfer Methods.” In International Conference on Knowledge Management in Nuclear Facilities. http://www.fraserhealth.ca/media/Implementation-of-Tacit-Knowledge-Presevation-and-Transfer-Methods.pdf. Ghosh, S., S. Negahban, Y.H. Kwak, and M.J. Skibniewski. 2011. “Impact of Sustainability on Integration and Interoperability between BIM and ERP - A Governance Framework.” In , 187–93. doi:10.1109/ITMC.2011.5995975. Hollingsworth, David. 1995. “Workflow Management Coalition - The Workflow Reference Model”, no. 1. “IT Catalysts.” 2013. IT Catalysts, Inc. http://www.itcatalysts.com. Kang, Youngcheol, William J. O’Brien, and James T. O’Connor. 2012. “Analysis of Information Integration Benefit Drivers and Implementation Hindrances.” Automation in Construction, Planning Future Cities-Selected papers from the 2010 eCAADe Conference, 22 (March): 277–89. doi:10.1016/j.autcon.2011.09.003. Krishnakumar, N., and A. Sheth. 1995. “Managing Heterogeneous Multi-System Tasks to Support Enterprise-Wide Operations.” Distributed and Parallel Databases 3 (2): 155–86. doi:10.1007/BF01277644. Lee, Laurence Lock. 2005. “Balancing Business Process with Business Practice for Organizational Advantage.” Journal of Knowledge Management 9 (1): 29–41. doi:10.1108/13673270510582947. O’Connor, James T, and Steven C Dodd. 2000. “Achieving Integration on Capital Projects with Enterprise Resource Planning Systems.” Automation in Construction 9 (5-6): 515–24. doi:10.1016/S0926-5805(00)00062-5. Project Change Management - Special Publication 43-1. 1994. Construction Industry Institute (CII). Shahi, A., C. Haas, J. West, and B. Akinci. 2014. “Workflow-Based Construction Research Data Management and Dissemination.” Journal of Computing in Civil Engineering 28 (2): 244–52. doi:10.1061/(ASCE)CP.1943-5487.0000251. Tang, Pingbo, and Burcu Akinci. 2012. “Formalization of Workflows for Extracting Bridge Surveying Goals from Laser-Scanned Data.” Automation in Construction 22 (March): 306–19. doi:10.1016/j.autcon.2011.09.006.   260-10  5th International/11th Construction Specialty Conference 5e International/11e Conférence spécialisée sur la construction    Vancouver, British Columbia June 8 to June 10, 2015 / 8 juin au 10 juin 2015   IMPLEMENTATION OF CONSTRUCTION INDUSTRY BEST PRACTICES  INTO WORKFLOW MANAGEMENT SYSTEMS Behrooz Golzarpoor1,2, Carl T. Haas1 1 Civil and Environmental Engineering Department, University of Waterloo, Waterloo, ON, Canada 2 bgolzarpoor@uwaterloo.ca Abstract: Several research studies have confirmed that identification and adoption of industry best practices drive performance improvements in terms of cost, schedule, and productivity. Best practices specifications facilitate the reuse of experience within a domain. However, they typically offer abstract suggestions and recommendations that include not only explicit, but also tacit knowledge. Key approaches of adopting and promoting best practices include socialization and face to face interactions, such as meetings, workshops, and training. These approaches, however, are not easily scalable to large capital projects, to provide systematic and consistent adoption of best practices throughout different phases of a project or among different projects. An alternative solution is to transform best practices into processes implementable into workflow management systems. In this paper, well-known best practices in the domain of the construction industry and their common characteristics are investigated. A framework is then established for transforming best practices into structured processes implementable into workflow management systems. Only parts of a best practice can be transformed into a structured process. The proposed framework describes which components of a best practice are more suitable for this transformation. The result is a process with the essence of a best practice that can be embedded into and automated through workflow management systems. This approach of integrating construction industry best practices into workflow management systems, not only facilitates consistent implementation of best practices throughout the project lifecycle and within projects, but also improves conformance to those practices, with the end result of improved capital project performance. 1 INTRODUCTION It is well established from statistical analysis of several projects that effective implementation of best practices and integration of information technologies are correlated with substantial improvements in project performance (Figure 1 & Figure 2). Research studies state that systematic implementation of best practices is one of the most important contributing factors to mega projects’ success (Chanmeka et al. 2012). A best practice might be a single procedure or method, but most usually it is a combination of several policies, rules, procedures, and methods, in a particular domain.     260-1 capital projects. An alternative solution is to transform best practices into workflow processes implementable into Electronic Product and Process Management (EPPM) systems – a type of workflow management system particularly being used for managing mega capital projects. This approach utilizes business process models and workflow engines to facilitate more consistent implementation of best practices throughout different phases of a project or among different projects. Fundamental improvements in communication and collaboration technologies and the increased use of EPPM systems – that are process-based and workflow-driven – in managing mega capital projects provided the required infrastructure, and facilitate putting this approach into practice. Utilization of EPPM systems and workflow engines offer the advantages of consistency, accuracy, and scalability, and thus can be considered a key tool for adopting best practices in mega capital projects. 2 BACKGROUND Mega construction projects typically involve many stakeholders from different parts of the world, with diverse organizational structures and cultures, and with distinct specialized expertise. A typical oil and gas project is comprised of a few owners, tens of general contractors, and hundreds of sub-contractors from different firms and disciplines, such as engineering, consulting, construction, and facility management; nevertheless, all striving towards the common goal of completing the project. This level of cooperation is made possible in part by advancements in communication and collaboration systems in the domain of information technology. This includes essential communication infrastructure provided by the World Wide Web, database management systems, and real-time data exchange services. Furthermore, such multilateral accomplishments have been aided by substantial improvements in systems tailored to projects and corporations. Examples include advanced project management tools, enterprise resource planning (ERP) (Chung, Skibniewski, and Kwak 2009; Ghosh et al. 2011; O’Connor and Dodd 2000), workflow engines (Tang and Akinci 2012; Cardoso, Bostrom, and Sheth 2004), electronic document management systems (Al Qady and Kandil 2013), knowledge-based information systems (El-Gohary and El-Diraby 2010; Kang, O’Brien, and O’Connor 2012), and more specifically electronic product and process management (EPPM) systems (Shahi et al. 2014). Electronic Product and Process Management (EPPM) Systems are the new technology trend for management of mega capital projects. Their core components are typically a combination of a workflow management system (WfMS), a document management system (DMS), and a collaboration management system. A workflow engine at the heart of the workflow management system facilitates enactment of workflow processes; a document management system supports several types of files and enables sharing and modifying various types of documents. The collaboration management system enables project delivery by collaboration among several stakeholders. The services that EPPM systems offer encompasses planning, coordination, and management activities within the product and project lifecycle. EPPM systems store and retrieve various types of information regarding the lifecycle of a project, and can be used to mine repositories to capture hidden knowledge, and analyze the acquired knowledge for more informed decision making. This knowledge is typically represented in the form of status and progress reports, lessons learned, cost and performance analysis, etc. through dashboards. Implementation of best practices into EPPM systems involves transforming practices into workflow processes. Thus, distinguishing the differences between practice, process, and workflow is vital. Before establishing a framework for practice to process transformation, this paper discusses these differences. 2.1 Process vs. Practice A process is a series of well-defined inter-related steps which delivers repeatable, predictable results. Key features of a process include 1) predictable and definable inputs, 2) linear, logical sequence, 3) clearly definable set of activities, and 4) predictable, desired outcome (Lee 2005). An activity is typically considered as a major unit of work comprising more detailed steps called sub-activities. Whenever an activity is considered as the smallest unit of work, it is called a task. A process is typically used in routine 260-3 circumstances in which repeatable, predictable results are required. Each necessary step is codified in detail and there is no spontaneous decision making involved. A process can be performed manually or can be automated through an information system. For an automated process, the inputs, outputs, and steps involved should be clearly defined; and to implement a process in a workflow management system it should be defined in a standard process modeling language. Typically, automated processes include both automated and manual activities. Request for Information (RFI) and Change Request (CR) processes are examples of such processes. Processes in which all of their activities are automated are called fully automated processes, such as the buying processes in Amazon or eBay. A practice, on the other hand, is a frequently repeated act, habit, or custom that needs a recognized level of skill to be performed. It is an un-codified knowledge that results from human experience and improvisation (Lee 2005). While a practice is still a series of steps, the steps are loosely defined, and the details of how to perform each step is left to the experts who perform them based on their knowledge, experience, skill, and judgment. Practices, thus, are more suitable for dealing with uncertain situations with uncommon or unique results (“IT Catalysts” 2013). Table 2 summarizes key differentiators of processes and practices. Table 2: Process vs. Practice Process Practice  Series of well-defined steps    Deliver repeatable, predictable results   Well-suited to mass production    Includes clear steps and details for tasks  Series of steps, but loosely defined  The specifics are left to the experts performing them  Appropriate for dealing with uncertain situations with unique results   Not necessarily have a clear sequence and details for tasks 2.2 Process Modeling Tools and Standards To implement a process in a workflow management system, it should be defined as a process model using a standard process modeling notation. Several process modeling languages and standards have been developed for modeling business processes. Process modeling can be performed either by representing a process using graphical notations or by representing the semantics of the process using modeling languages. Using graphical notations is more convenient for communication, reengineering, and improvement of processes. Recent modeling tools such as XPDL and BPMN support both a graphical notation and a modeling language. A classification of the most popular modeling tools and standards is presented in Table 3. Table 3: Process Modeling Tools and Standards Classical More Formal Most Recent Flowchart 1920s Functional Flow Block Diagram (FFBD) 1950s Data Flow Diagram (DFD) 1970s ICAM DEFinition (IDEF0) 1970s Petri nets 1960s Workflow patterns YAWL Graph-Based Workflow Language UML 1997 XPDL 2002 BPEL 2004 BPMN 2004 Business Process Modeling and Notation (BPMN) is the most promising process modeling standard. It has been designed by the Object Management Group (OMG) with the aim of identifying best practices of existing modeling tools and combining them into a widely accepted, easy to use language. The same process model in BPMN may encompass different levels of details, each useful for a particular group of 260-4 stakeholders, from business administration people to business analysts and software developers. BPMN defines three levels of process modeling conformance. ‘Descriptive level’, useful in high-level modeling, only includes visible elements and attributes; ‘analytic level’ includes descriptive and a minimal subset of supporting process attributes; and ‘common executable’ offers the elements required for execution of process models. In this paper we use BPMN 2.0 notation for representing sample process models. 2.3 Workflow vs. Process Workflow and process are similar terms and, in certain situations, might be used interchangeably. However, workflow implies a more specific concept than process. While any group of well-defined interconnected steps with an expected result can be called a process, in a workflow the focus is on the piece of work or information that is being passed through initiation to completion. Therefore, a workflow associated with a particular process might not be involved with all the details that are important for completion of the process, such as recording to a database or calling a web-service, but is more dedicated to the flow of work through all the steps. A workflow thus can be defined as an outline or blueprint of a process. A summary of process and workflow differences are presented in Table 4. Table 4: Process vs. Workflow Process Workflow  A process is a series of well-defined inter-related steps  A process is modeled using modeling tools and implemented by coding the steps  A process can be modeled with different abstraction levels: organizational, operational, and implementation levels  The focus is on steps of work  A programmer typically implements a process  A workflow is considered as an outline of a process  The flow of work in a workflow can be updated without changing underlying code  The focus is on organizational details, but can include operational and  implementation-level details  The focus is on the flow of work  A analyst typically can modify the steps and update the flow of a workflow 2.4 Workflow Management Systems (WfMS) Workflow management and workflow specification are concepts tightly related to business process management and process modelling; however, their approach is rather different. Workflow management involves the automation of processes which are comprised of human and machine-based activities (Hollingsworth 1995) and focuses on the flow of information or work among participants. A workflow specification is an abstraction of a process that might not be concerned with all the details of a task, but in any case it is concerned with the inter-relationship, the inputs and outputs, and the externally visible behavior of tasks (Krishnakumar and Sheth 1995).  Automation of business processes partly relies on the coding of software developers for embedding business processes into information systems. Originally, any modification to the process logic, the sequence of activities, and the execution constraints of a process was affecting the programming code and required software developer’s attention. The introduction of object-oriented programming concepts facilitated the separation of process logic modifications from the programming code, and led to the emergence of workflow driven systems. In a workflow management system, features of an application, or tasks of a process, are defined as steps in a workflow, and therefore, the behavior of the system can be modified through changing the steps without any modification to the programming code. Workflow technology, thus, provides separation of business process logic from IT operational support (Hollingsworth 1995).  260-5 A workflow engine is responsible for managing and enacting tasks within workflow specifications according to their execution constraints and organizational predefined rules. The execution constraints of a process are typically defined as properties or attributes of tasks in the workflow specification. The Workflow Reference Model (Hollingsworth 1995), developed by the Workflow Management Coalition (WfMC) is a key reference for workflow management systems and their interfaces. Workflow management systems facilitate more convenient design and implementation of processes with less involvement in programming details. 3 PROPOSED FRAMEWORKS A best practice is a guideline to an improved way of organizing and performing a work. The steps offered in a best practice does not necessarily include well-defined sequence and details, and thus it typically relies on the skills and experience of the actor to fill the gaps, whereas in a structured process the sequence of activities and their execution constraints are completely defined. This paper proposes two frameworks for transformation of best practices into structured processes suitable for implementation via workflow management systems. The frameworks explain how the inherent knowledge of a best practice can be combined with the key characteristics of a structured process, such as well-defined steps, sequence, and execution constraints. In addition, the frameworks clarify how the components of a best practice can be associated with elements of a structured process. 3.1 A Conceptual Framework A practice as a form of knowledge includes explicit, tacit, and implicit types of knowledge (Anand and Singh 2011; Faust 2007). The explicit is the category of knowledge that can easily be identified, codified, stored, and retrieved, and thus, its implementation and automation is relatively straightforward. Interrelated components of a best practice comprising explicit knowledge can be defined as a high level organizational process. Tacit knowledge is inherent with the skills and experience of people, and is hard to capture and codify, and thus, cannot easily be automated. Tacit knowledge or judgmental steps in a practice can be embedded into manual human-tasks of a process. A fraction of tacit knowledge, that is hard but possible to capture and make explicit, is called implicit knowledge. Implicit knowledge is associated with how a process is defined and how it is implemented. It affects the way a process behaves. Table 5: Types of Knowledge in a Practice and their Association with a Process Practice Components … Association with … Process Elements Explicit Knowledge Tacit Knowledge Implicit Knowledge … What is done … … Who accomplish … … How is defined … Structure of the Process Human-tasks of the Process Behavior of the Process Accordingly, we can associate elements of a process with components of a practice. The structure of the process – which defines what is performed – can be defined based on the explicit knowledge present in the practice. The human-tasks of the process – which is related to who has the capability of performing the task – are associated with the tacit knowledge of the practice. The behavior of the process – which is consistent with how the process is defined – signifies the implicit knowledge of the practice (Table 5). 3.2 A Practical Framework The practical framework for transformation of a best practice into a process involves two main steps: (1) identify the related components of a best practice and define them as one or more high-level organizational processes, and (2) transform the organizational processes into well-defined structured processes suitable for implementation via workflow management systems. These steps are presented in Figure 3 and are discussed with examples in the following sections.  260-6 Acknowledgements This research is funded by the Natural Sciences and Engineering Research Council of Canada (NSERC) and Coreworx Inc. Their support is gratefully acknowledged. References Al Qady, M., and A. Kandil. 2013. “Document Discourse for Managing Construction Project Documents.” Journal of Computing in Civil Engineering 27 (5): 466–75. doi:10.1061/(ASCE)CP.1943-5487.0000201. Anand, P., and M. D. Singh. 2011. “Understanding the Knowledge Management.” International Journal of Engineering Science and Technology 3 (2): 926–39. Cardoso, Jorge, Robert P. Bostrom, and Amit Sheth. 2004. “Workflow Management Systems and ERP Systems: Differences, Commonalities, and Applications.” Information Technology and Management 5 (3-4): 319–38. doi:10.1023/B:ITEM.0000031584.14039.99. Chanmeka, Arpamart, Stephen R. Thomas, Carlos H. Caldas, and Stephen P. Mulva. 2012. “Assessing Key Factors Impacting the Performance and Productivity of Oil and Gas Projects in Alberta.” Canadian Journal of Civil Engineering 39 (3): 259–70. doi:10.1139/l11-128. Chung, B., M.J. Skibniewski, and Y.H. Kwak. 2009. “Developing ERP Systems Success Model for the Construction Industry.” Journal of Construction Engineering and Management 135 (3): 207–16. doi:10.1061/(ASCE)0733-9364(2009)135:3(207). El-Gohary, N., and T. El-Diraby. 2010. “Dynamic Knowledge-Based Process Integration Portal for Collaborative Construction.” Journal of Construction Engineering and Management 136 (3): 316–28. doi:10.1061/(ASCE)CO.1943-7862.0000147. Faust, B. 2007. “Implementation of Tacit Knowledge Preservation and Transfer Methods.” In International Conference on Knowledge Management in Nuclear Facilities. http://www.fraserhealth.ca/media/Implementation-of-Tacit-Knowledge-Presevation-and-Transfer-Methods.pdf. Ghosh, S., S. Negahban, Y.H. Kwak, and M.J. Skibniewski. 2011. “Impact of Sustainability on Integration and Interoperability between BIM and ERP - A Governance Framework.” In , 187–93. doi:10.1109/ITMC.2011.5995975. Hollingsworth, David. 1995. “Workflow Management Coalition - The Workflow Reference Model”, no. 1. “IT Catalysts.” 2013. IT Catalysts, Inc. http://www.itcatalysts.com. Kang, Youngcheol, William J. O’Brien, and James T. O’Connor. 2012. “Analysis of Information Integration Benefit Drivers and Implementation Hindrances.” Automation in Construction, Planning Future Cities-Selected papers from the 2010 eCAADe Conference, 22 (March): 277–89. doi:10.1016/j.autcon.2011.09.003. Krishnakumar, N., and A. Sheth. 1995. “Managing Heterogeneous Multi-System Tasks to Support Enterprise-Wide Operations.” Distributed and Parallel Databases 3 (2): 155–86. doi:10.1007/BF01277644. Lee, Laurence Lock. 2005. “Balancing Business Process with Business Practice for Organizational Advantage.” Journal of Knowledge Management 9 (1): 29–41. doi:10.1108/13673270510582947. O’Connor, James T, and Steven C Dodd. 2000. “Achieving Integration on Capital Projects with Enterprise Resource Planning Systems.” Automation in Construction 9 (5-6): 515–24. doi:10.1016/S0926-5805(00)00062-5. Project Change Management - Special Publication 43-1. 1994. Construction Industry Institute (CII). Shahi, A., C. Haas, J. West, and B. Akinci. 2014. “Workflow-Based Construction Research Data Management and Dissemination.” Journal of Computing in Civil Engineering 28 (2): 244–52. doi:10.1061/(ASCE)CP.1943-5487.0000251. Tang, Pingbo, and Burcu Akinci. 2012. “Formalization of Workflows for Extracting Bridge Surveying Goals from Laser-Scanned Data.” Automation in Construction 22 (March): 306–19. doi:10.1016/j.autcon.2011.09.006.   260-10  Implementation ofConstruction Industry Best Practicesinto Workflow Management SystemsByBehrooz GolzarpoorCarl HaasInternational ConstructionSpecialty ConferenceJune 2015Outline Introduction & Motivation Process vs. Practice Process vs. Workflow Conceptual Framework Practical Framework Summary2Slide Introduction Best practices are guidelines  They enable the reuse of experienceOrganization Guidelines referred asConstruction Industry Institute (CII) Best PracticesConstruction Owners Association of Alberta (COAA) Best PracticesIndependent Project Analysis (IPA) Value Improving Practices (VIPs)Project Management Institute (PMI)Foundational and Practice StandardsConstruction Management Association of America (CMAA)Standards of PracticeThe Association for the Advancement of Cost Engineering (AACE) InternationalProfessional Practice Guides (PPGs)Process Industry Practices Practices3Slide Introduction Typical adoption approaches Socializations and face-to-face interactions Meetings / Workshops Training / Mentoring Challenges Offered at an abstract level Adoption approaches are not scalable Adoption is not consistent from project to project4Slide Introduction Electronic Product and Process Management (EPPM) SystemsWorkflow Management SystemDocument Management SystemCollaboration Management SystemContent Management Systemhttp://www.cda-it-systems.com/referenzen.html5Slide Motivation Systematic adoption of best practices is one of the most important contributing factors to mega projects’ success (Chanmeka, Thomas, Caldas, & Mulva, 2012) Most construction best practices are process oriented (CII) The popularity of EPPM systems in mega capital projects is growing – The infrastructure6Slide Process vs. Practice Process is a series of well-defined steps. Practice is a series of steps, but loosely defined.ExplicitWisdomKnowledgeInformationDataPracticeProcess7Slide Conceptual FrameworkPractice ComponentsExplicitTacitImplicitAssociation… What is done …… Who accomplish …… How is defined…Process ElementsStructureHuman-tasks Behavior8Slide Practical FrameworkBest PracticeConstruction IndustryBestPractices----------MightInclude  Organizational Level ProcessesOrganizational LevelProcessNot directly implementable in WfMS----------Informal and Semiformal TechniquesOperational LevelProcessBusiness Analysts----------Business Process ModelsImplementation LevelProcessSoftware Developers----------Programming Languages9Slide Organizational Level ProcessPromote a Balanced Change CultureContinuously ImproveEvaluate Change Implement ChangeRecognize Change• Encourage beneficial change• Discourage detrimental change• Communication• Documentation• Trending• Authorization• Documentation• Tracking• Classify Change• Conduct Impact Analysis• Determine Funding Source• Share lessons learned• Be prepared to improveRFI & Other ProcessesChange Request (CR) ProcessEPPM System ProcessesLessonsLearned ProcessMostlyTacit Knowledge10Slide Organizational Level Process3.1 Determine the time frame for change decision.3.2 Collect data needed.3.3 Identify impacts.3.4 Determine final funding source or “who pays” (cost reimbursable, design development, lump sum, and others). If applicable, confirm the interim funding source decision.3.5 Re-evaluate project feasibility with proposed change included.3.6 Authorize change and send out notice to all affected organizations/disciplines.11Slide Process vs. WorkflowProcess Workflow A process is a series of well-defined inter-related steps A workflow is considered as an outline of a process The focus is on steps of work  The focus is on the flow of work A process can be modeled with different abstraction levels: organizational, operational, and implementation levels The focus is on organizational details, but can include operational and  implementation-level details A software developer typically implements a process by coding the steps A analyst can modify the steps, and update the flow of a workflow without changing the underlying code12Slide Operational Level Workflow13Slide Implementation Level Workflow14Slide Summary• Best practices typically include several components.• Related components can be defined as high-level organizational processes.Practice• High level processes include explicit, tacit, and implicit knowledge.• Explicit knowledge can more easily be transformed into structured processes.Organizational Process • The roles and responsibilities play and important role.• Structured processes can be implemented into workflow management systems.Structured Process15Slide Q & AThank You!

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.52660.1-0076444/manifest

Comment

Related Items