This time my article is about BCF-BIM Collaboration Format. Again, the definition of bimdictionary first:
"A schema used for exchanging information and model viewpoints between individuals irrespective of the software tools used. Implemented as both an XML file (bcfXML) format and a RESTful API webservice (bcfAPI), the Open BIM Collaboration Format (BCF) is typically used to highlight issues discovered during model reviews. The schema allows for the exchange of comments and images linked to specific Model Components through their unique Global Unique IDentifiers (GUID)"
How was life before BCF? I want to examine this question under two separate headings:
How were the CAD projects before BCF progressing?
Let's say we use the CAD system (I explain this issue taking into account the conditions of Turkey). In general, data sharing of a project stakeholder with other stakeholders is not within the framework of established rules. I mean the rules; in order for the project to proceed, it is not defined who will share which data, what quality, and at what intervals with other stakeholders. In the absence of such a scheme, the process goes by phone, Whatsapp messages, and the most dangerous one is by e-mails. I want to explain why emails are the most dangerous in a simple way: Imagine a project with 10 project stakeholders. While team 1 advances the project, they send the current status of the project to team 2 by e-mail regarding a situation that concerns them. While team 2 develops its own projects (let's say structural model), a situation involving teams 4 and 7 occurs, and team 2 sends his model to team 4 and 7 by e-mail. At best, 1 day later, there will be 4 different variations of the same project (team 1, team 2, team 4 and 7, the rest). Of course, this situation progresses exponentially with the second phone call and e-mail traffic (of course this is the situation where we don't have a communication and sharing policy). I think this is obvious that having data sharing and communication protocols is so important. Unfortunately, when we look at the situation in regard to the employer, this situation gets worse (at least in my country). The main danger occurs when the employer is also the contractor. As the project teams advance the project, the contractor requests the drawings (in DWG file format). Now let's think about it for a while. What is the purpose to request the drawings in the DWG file format? Of course to revise the project instead of marking it up. Does s/he have the authority to sign that (changed) documents? Of course not. Will s/he take responsibility when there is a coordination problem with other disciplines? I don't think so. I completely set aside that it is disrespectful behaving. So what is the contractor's argument here: "I give the money".
So how did BIM projects progress before BCF?
They did not progress very well either. Although Common Data Environment (CDE), communication protocols, and processes were defined, each discipline was trying to advance the project by sharing files that are too large. I recommend you read this link about it:
I've published an article about IFC before. If IFC provides model and data sharing between BIM programs, BCF also enables us to manage communication processes. When we encounter a problem by using our checking software, we can create an issue. You can assign these issues to the person or team, and you can also exchange ideas to solve these issues by using BCF. You can close the issues that have been corrected. And you can do all of them in a very elegant way.
Let's have a look at how BCF solves these problems:
Large file transfer. BCF can transfer GUID (Global Unique Identifier) data with the camera and target coordinate. For example, while checking your project as a manufacturer (by using Tekla), let's assume that you see a clash with the HVAC project that is designed in Revit and transferred by using IFC. If you transfer the issue you created in Tekla to the mechanical engineer by using BCF, the mechanical engineer can activate the issue in Revit, see the problem from the point exactly structural engineer created. Since only the communication about the issue and the camera and target location will be transferred, the file size will be considerably smaller.
Dozens of emails for an issue. Perhaps you send e-mails to other stakeholders many times to solve a problem. It is very difficult to reach the history of correspondence about this issue. Let me explain. Even if there are 100 issues in a small project, if you write email 10 times about them, I am talking about 1000 emails about these 100 problems. Since BCF transfers all these correspondences by linking them to related issues, you can see all past comments about the issue when you view it.
The availability of the problem location. Even if you send a screenshot of the problem in a large project, you won't know exactly where that problem is. Especially when there exist repetitive rooms, like hospitals or office buildings, or large areas like airports. However, thanks to BCF, you view the situation with the eye of the person who created the issue. This allows you to get rid of any misunderstanding (of course you can find the problem with element ids or interaction between programs, but none of them is as simple and effective as BCF).
Business intelligence. I think one of the important issues is reporting. It is impossible to prepare reports in the processes carried out by e-mail regarding the types of issues, the origin of them, the average time of the issues to be resolved, which disciplines, in general, are delayed in solving the issues, the source of revision requests, the project stage, the number of problems by location or priorities, and many more. However, when using BCF, all this can be reported up-to-date and provide data to business intelligence. This allows us to make our decisions more carefully in the next project.