Operational process models

Once the process was outlined in a strategic model, it was mapped at an operational level as described in Section 5.3.3. These operational models are valuable for understanding the specific tasks that have to be carried out and contribute towards the creation of models which can be parsed by the workflow engine. Once the workflows that could potentially be carried out within the engine had been identified, they were taken into consideration when developing the prototype process management system. This step in the process discovery stage had 4 objectives:

1. Separating lanes into separate pools on an organisational level (description of annotation used can be found in Section 3.2.2.1)

2. Once the pools were created, understanding the process from each participants point of view

3. Establish information requirements for the tasks

4. Identify which tasks or workflows could be supported by the process engine The purpose of separating the BPMN ‘lanes’ into individual ‘pools’ was to highlight that each organisation has its own specific systems and tasks and therefore each organisation sees the process from a different point of view. By creating separate pools, it helps clarify what information is shared between each organisation and how certain tasks are completed within the organisation.

Figure 5-4 and Figure 5-5 describe a high-level overview of the capture of as-built information as well as the interaction between the asset operator and the lead appointed party.

Figure 5-6 and Figure 5-7 show the process and a subprocess of the interactions between, designers, lead appointed parties and asset operators when preparing asset information which can eventually be used for maintenance planning. The subprocess helps identify the main tasks that are carried out by the asset operator when validating the information imported into their asset management systems. Then the process related to snagging/punch listing is described in Figure 5-8 which shows the main steps where minor defects on a recently completed job will be identified and resolved. Figure 5-9 then shows a more detailed breakdown of the process and the interaction between

122

the lead appointed party and the asset owner or their representatives. Each of the workshops had a specific theme which helped with understanding of the different points of view based on the role of the organisations and participants.

123

Figure 5-4 Process map describing process of capturing as-built information – Operational process model

124 Figure 5-6 Preparation of asset information – Operational process model

125 Figure 5-8 Handover preparation – Operational process model

126 Figure 5-9 Snagging (linked to Figure 5-8) – Operational process model

127

5.7 Discussion

This chapter first aimed to validate the findings made on the EBL project and to identify whether the challenges that were faced were common throughout the industry. It was confirmed that they were and that they could be categorised under three broad headings as technological, SMP and process related and human and administrative issues. By identifying the individual challenges faced under these categories it provides an opportunity to ensure that they can be mitigated or avoided in future projects.

While information on the challenges being faced on projects were being gathered, three scenarios were formulated in order to understand what should ideally happen when implementing VDC and what triggers potential issues with the production or the quality of the asset information.

Scenario 1 was the most ideal in which all participants are aware of how they will create and utilise the information. This type of scenario will have all the requirements aligned with the industry SMP’s and also have an appropriate contractual framework in place to ensure that the appropriate processes are implemented as needed. As there is a growing awareness of the VDC and its related standards the occurrence of this scenario should become more likely.

Scenario 2 is currently the most common the various organisational processes and standards do not align with each other and do not completely follow the industry standards. This may be attributed to ambiguities in the standards or to challenges faced when attempting to adopt them.

As a result of these findings an assumption was made that the likelihood of Scenario 3 occurring will reduce as there is a growing awareness of the benefits of implementing VDC over the lifecycle of a project. Upon analysis the aim would therefore be to ultimately shift towards Scenario 2 and then 3 type projects.

To aid the achievement of scenario 1, strategic process maps were created to understand the basic tasks that need to be carried out and the documentation that has to be created in order to ensure the streamlining of information over the course of an asset’s lifecycle. These strategic process maps were then broken down further in order to define individual organisational processes from which operational process maps

128

(human workflows) could be created. These process maps are beneficial as they can help organisations identify the uses of the information that is being generated.

Using these processes, a prototype system was developed to help automate some of the tasks defined in them and this will be described in detail in the following chapters. This prototype was validated by presenting some of the strategic process maps to engineers working on a Scenario 1 project and to further develop the processes so that they addressed the project specific information requirements.

The findings in this chapter were expected to first validate the conclusions made in the previous chapter, and then explore how the problems that were identified in Chapter 4 can be addressed. The findings made during these workshops showed that there is a need to ensure that specific information requirements are set, and processes are governed in order to ensure that these requirements are met.

A potential solution to alleviate the problems faced in Chapter 4 was to explore if the processes recorded in this chapter (1) can be automated (Chapter 6) and then (2) implemented on a project based on specific requirements (Chapter 7). Therefore, the next two chapters therefore aim to test the findings made in this chapter first on a technical level, and then on a practical level respectively. Testing the findings made in this chapter will contribute to the existing body of knowledge as it will help asset owners/operators enforce their requirements, and it will help suppliers improve the accuracy of the asset information they provide to their clients.

5.8 Conclusion

This chapter aimed to answer research question 3:

Upon identification of the main causes that hinder the adoption of BIM/VDC and affect the development of the AIM, how can current construction processes be redefined to alleviate these issues?

This series of workshops was beneficial for understanding the interactions between various organisations and their organisational level processes that eventually influence on the flow of project information. This chapter has presented the creation of a strategic process map and a set of operational process maps based on the points of view of

129

individuals involved in various functions from a range of organisations. Answering this research question contributes towards:

- Understanding problem areas faced by all organisations involved in a project, and the knock-on effects they may have

- Identifying common scenarios that occur which affect the quality of the AIM and lead to potentially costly rework for the appointed parties involved

- Defining a strategic level process map and operational level process maps which are beneficial for identifying the way information is exchanged and developed within organisations based on their function.

130