Analyzing and gathering process requirements starts with finding all stakeholders. Let's imagine a company has a project where the client makes a new request - "add an additional window on the north side of the building".
The small process of "client request to add a new window to the current project" involves the architect, client, CAD (BIM) specialist, construction manager, logistics manager, ERP analyst, quality control engineer, safety engineer, control manager and real estate manager.
Even a small process can involve dozens to hundreds of different specialists. Each process participant needs to understand the requirements of the specialists to whom they are linked at the data level.
At the textual level, the communication between the client and the specialists is as follows:
➤ Customer: "We have decided to add an additional window on the north side for better lighting. Can this be realized?"
➤ Architect: "Of course, I will revise the design to include the new window and send updated CAD (BIM) plans."
➤ CAD (BIM) specialist: "Got a new project. I update CAD (BIM) model with additional window and after coordination with statistician I provide exact location and dimensions of new window.
➤ Construction Manager: "New design received. We adjust the timing of 4D installation and inform all relevant organisations".
➤ Facilities Engineer (CAFM): "I will enter 6D data on the new window into the CAFM system for future facility management and maintenance planning."
➤ Logistics Manager: "I need the dimensions and weight of the new window to organize the delivery of the window to the site."
➤ ERP Analyst: "Updating the 5D budget in our ERP system to reflect the cost of the new window in the overall project estimate."
➤ Quality Control Engineer: "Once the window specifications are ready, I will make sure they meet our quality and material standards."
➤ Safety Engineer: 'I will assess the safety aspects of the new window, focusing on compliance and 8D evacuation.
➤ Controls Manager: "Let's update our 4D timeline to reflect the new window installation and save the new data into the project's content management system."
➤ Worker (installer): "Need instructions on installation, assembly, and lead times. Also, any special safety protocols I need to follow?
➤ Property Manager: "Once installed, I will document warranty and maintenance information for long-term management."
➤ Asset Manager: 'Equipment Engineer, please send final data for asset tracking and lifecycle management'.
➤ Client: "Wait, maybe I'm in a hurry and the window won't be needed. It might be worth making a balcony.".
In this scenario, communication between different professionals, including the client and the architect, occurs predominantly through textual data such as emails, dialogs, calls and meetings.
The textual layer of client-performer communication contains multiformat textual data
In such a text-based communication system for a construction project, a system of legal confirmation and recording of all data exchange transactions and all decisions made is essential. This is to ensure that every decision, instruction and change made is legally valid and traceable, reducing the risk of misunderstandings in the future.
The lack of legal control and confirmation of decisions in the relevant systems of a construction project can lead to serious problems for all involved. Every decision, instruction or change made without proper documentation and confirmation can lead to disputes and legal proceedings.
Lack of text transaction confirmations not only delays the project but can also lead to additional financial losses and deterioration of relationships between project participants.
Legal fixation of all decisions in text communication can be ensured only with a large number of signed documents, which will fall on the shoulders of the management, which will be obliged to record all transactions. Text-based communication require each specialist to either familiarize himself with the full correspondence or to participate in all meetings on a regular basis to understand the current status of the project.
Each system in the landscape of construction companies serves as a source for legally relevant documents in different formats
In order to move from textual communication and textual records of "decision-making operations" to the system level, methods for converting textual operations into a more structured and usable format are needed. As in data modelling (Figure 2.5-2), we moved from the contextual-idea level to the conceptual level, adding the systems and tools used by participants and the links between them.
To learn how to manage and automate the validation process it is necessary to visualize and structure the requirements
And the first step in systematising requirements and relationships is to visualise all links and relationships with the help of visual flowcharts. The conceptual level not only makes it easier for all process participants to understand the entire process chain, but also visualises why and for whom data is needed at each process step.
