BIM案例｜设计模型向施工的传递

发布时间：2017-10-26 02:26 来源：JoyBIM 作者：JoyBIM QQ群：567366607

背景

去年年初的时候,一个BIM会议让我邀请美国的一些同行来国内做交流，于是我把前Balfour Beatty CTO 现Black&Veatch CTO Brad Hardin还有McCarthy的BIM Director Dave McCool请到了国内。这两个人正好也好也是《BIM and Construction Management》的作者。

当时Brad Hardin直接做了一个关于大数据的演讲。而Dave McCool为演讲的题目仔细地斟酌了下，最后他说：我来针对行业痛点——施工单位无法使用设计模型，来讲点大家都感兴趣的话题吧——设计模型如何传递给施工单位。

Dave McCool证求了我的意见，并把大纲给我看了下。我说这个题目挺不错的，就是国内的听众最后听下来会简单的认为你只是简单的讲了3D和碰撞检测，国内的听众可能更想要的是高大上的“黑科技”。

后来Dave McCool还是坚持了自己的想法，因为Loma Linda项目和多年前GSA的Edith Green一样，是美国近年来如教科书般的经典案例。但后来会上的交流反响确实也一般，虽然我尽可能地做好了翻译，但是还是得到了诸如“美国BIM应用也不过如此”的反响。

我知道如果单纯地再把这个案例拿出来将肯定还会得到类似的响应，所以在写这篇文章之前，我花了7篇文章做了铺垫。

项目概况

项目渲染图

项目名称：Loma Linda 大学医学中心

建筑面积：10万平米

合同额：8.23亿美元

建筑设计：NBBJ Architects

结构咨询：Arup

总承包：McCarthy

主要分包单位：Southland，Pan-Pacific，Stantec等

交付模式：Design Assist

项目采用的是Design-Assist Delivery 交付模式，但是实际上在实施过程中借鉴了很多IPD的思路。

对技术的误解

由于目前行业上不同BIM平台间模型交互的制约，使得很多人把施工无法使用设计BIM模型的原因归结到行业的整体技术层面。其实解决这个问题的方法很简单，就是让设计与施工单位使用同样的BIM软件。但如果假设设计与施工使用同样的软件了，那施工单位可以用设计的模型了吗？答案肯定是“不”。所以问题不是在BIM平台上。

设计模型与施工模型

还有很多人会说设计信息无法传递给施工造成了施工单位无法使用设计单位的BIM模型。但是这样的说法比较片面，因为信息其实对施工单位使用设计模型的影响很小，现阶段施工所需的设计模型信息主要还是在几何信息和对象识别上。所以问题也不是出现在信息的传递上。

所以很长一段时间，我们把问题的出现归结于了技术层面，使得我们忽略了从自身去寻找解决问题的方法。以至于多少年过去了，我们还在说着“施工无法使用设计模型”这个多年前的痛点，但从没有思考过造成这个痛点的真正原因。

制约的原因

McCarthy研究发现，制约我们施工使用设计模型的最主要原因其实是我们周而复始的设计习惯——由于反复的设计变动造成了施工无法正常使用设计模型。

周而复始的设计过程

McCarthy提出了一个假设，如果设计和施工采用的是同一个BIM软件，并且假设设计模型提交给施工单位后不再有变更不再有设计模型更改，那施工单位能不能使用设计模型？这个时候答案变成了“Yes”

所以McCarthy认为造成目前施工无法使用设计模型这个现状的最大原因，其实是我们自己——人。

进步的阻碍——人

整体思路

Loma Linda 发现，我们在实施项目时，长久以来都按照工作的对象来制定我们的流程，但是却忽略了工作实施的主体——人。

人性的本质使得人永远只会站在自己利益的一方。传统的工作模式让项目的各个参建者处于不同利益方的境遇。比如我们传统的建造流程都是按照建筑的实施顺序进行划分：业主-设计-总包-分包，于是形成了我们长期以来一直沿用的Design-Bid-Build模式。Design-Bid-Build模式将我们实施项目的主体按照利益进行了区分，而不是按照项目实施解决问题本质进行区分。

所以我们会出现下图中的人性：我们总是乐此不疲的看着并期望对方出错，并认为这是对自己有益的。而站在项目的角度上讲，我们每个人都是输家。所以角度不一样，我们的人性也不一样。

项目管理中的人性

所以Loma Linda 的目标是通过对项目管理的流程再造、体系整合，绑定各参与方拥有共同利益，从而使我们的设计达到Linear Construction Behavior这样理想的状态。

我们的期望：Linear Construction Behavior

组织的再造——Clusters

传统的组织模式

Cluster

传统的建造过程中，我们按照自己所在的阵营进行群聚，即业主、设计、施工。所以为了完成项目，每个团队都必须配足专业：建筑、结构、机电、装饰等等。于是我们的协同开始变得复杂：每个团队内部的专业需要协同，不同团队间的相同专业需要协同，不同团队间的不同专业需要协同。

传统组织下的沟通

Cluster间的逻辑

于是，我们协作间的冲突不仅仅在不同的利益团体间，也存在于我们同一阵营中的不同团队。效率变得不断低下。我们原本应该像施工顺序一样的线性过程变得周转与反复。用国内特有词汇来说，就是：扯皮。

针对传统组织模式所带来的局限，Loma Linda项目采用了Cluster Group的工作方法：Cluster Group跨越了业主、设计、施工的界限——项目按照专业重新对组织进行划分。也就是说在Loma Linda项目Cluster Groups里没有单位的之分，只有专业的划分，一个专业是一个Gluster Group。

项目的Cluster Groups

每个Cluster Group成员由同专业的业主、设计、施工总包、分包组成。

每个Cluster Group的成员构成

就这样，项目的组织架构开始发生改变，不再像传统的按照单位或利益不同体进行区分，而是回到了项目实施的本质，按照专业进行划分。

传统的项目架构之外，每个单位还会有自己的组织架构和沟通机制。Cluster Groups的存在，原来协同的反复交叉不再存在。因而采用Cluster Groups这样的组织架构，沟通的路径开始缩短。

基于Cluster Groups的项目架构

当出现一个问题后，不再会有业主、设计、总包、分包的反复沟通与协同，所有的问题会由对应的Cluster Group进行裁定，最后变成需要协定的Design Issue，以消除传统协同的冗余过程。

沟通的冗余消除

同时，由业主、设计、总包、分包的核心人员组成了整个项目的Core Team，这个Core Team是整个项目所有争端和问题的最终裁决团队。

于是项目的实施过程从最小的各专业Clusters开始，Clusters的成员识别并解决问题，需要协同的由Big Room讨论并解决（下面会提到Big Room）。最终所有的解决方案或是争端由项目Core Team进行裁决。

沟通的力量——Big Room

McCarthy提出了这样的一个双曲线：越是传统的沟通方式，沟通就越是有效，信息的传递也更清晰。反而越是现代化（anti-social）的沟通越容易产生信息传递的模糊。

沟通的有效性

所以虽然现在的行业大肆宣传异地环境下的协同工作，Loma Linda还是坚持选择了用最传统的Big Room作为各个团队间协同的方式，即项目所有的参建方的所有人员都在同一个地点工作。通过这样的方式，来确保沟通的最有效性。

Loma Linda项目Big Room

所以虽然BIM协同平台有各种各样的协作模式和方法，Loma Linda还是很坦然地把协同平台定位成“FTP site”，主要目的就是确保各参建方信息源的统一，以及过程文集和里程碑文件的储存。

协同平台的定位

不过有一点需要澄清的是，Big Room的工作方式不代表协同的丢失，但是这个协同更多的体现在工作的工具与方式上，而不是在沟通上。比如用360 Glue 代替传统的Navisworks，使得单一线性的设计协调，变成了多线共享的工作机制，而沟通的方式还是采用Big Room。

工作的协作

计划的再造——Coordination Alignment

Dave McCool在Loma Linda项目演讲中提到：我们在总包阶段对设计与深化设计的协同受制于建造顺序的思想，即按照建造的顺序进行着设计、深化与综合协调，以高层建筑为例，我们按照自下而上与施工的一致的顺序进行着我们所有的设计工作。

传统的设计流程

所以我们的设计与深化设计的进度如下图所示。但是项目在设计的前半段时期以及大楼下部公共区域的设计，是业主产生变更频率最高的时间和区位。

传统设计进度的风险

由于预制和现场施工的需求，深化设计以及协调往往按照和设计一样自下而上的顺序进行，那在深化设计最开始切入的时候便会遇到如上图所示的设计变更高发区域。这样的设计流程使得总包陷入了不断反复的设计与修改之中。

这是造成Iterative Design Behavior的原因之一。

针对业主决策存在“摆动期”，以及对公共区域方案决策困难的特性，Loma Linda对设计流程进行了再造与优化，寻找设计与深化设计之间协同融合的最佳切入点。

因为公共区域是业主最难决策的区域，并且项目实施的初期也是业主想法变化最多的时期，所以在一开始宏观的设计与协调中，Loma Linda决定工作重心首先从标准层开始。因为标准层由于功能性的限制，往往是业主最容易确定方案并且变更频率较低的区域。

第一轮以设计为主线的协调

在第二轮的设计协调中，便以深化设计所需要的顺序为主，即按照现场实施的需求进行。

第二轮以深化设计为主线的协调

这样工作流程使得项目的设计进度变成如下图所示。设计与深化设计会在最容易出现变更的区域交汇，我们把这个交汇的时间轴线叫做Coordination Alignment。

Coordination Alignment

由于设计和协调流程的再造，项目各参与方可以清晰地认识到协同工作的关键时间轴。由于设计的流程优化，使得最易出现变更的时间节点延后，业主的决策周期延长，同时这个时间点也是分包深化设计刚开始的节点。在这个时间区间，三方都处于一个Alignment状态，在最佳的时期共同解决同一个区域的相同问题。协同效率大大提升。

计划的再造——Increment Schedule

Coordination Alignment是宏观的流程再造，那Incremental Schedule便是在宏观的基础上对各个部位的细部再造。

和传统的建造DBB流程一样，我们对设计的流程定义也都是简单粗暴的线性状态。比如在美国，设计被简单的一刀切成Conceptual, SD，DD，CD四个状态。

设计的阶段性

Loma Linda项目团队在实施过程中发现，因为决策周期和设计关联性的问题，如果一个建筑整体严格按照SD/DD/CD进行划分，带来的结果往往是部分区域的设计不成熟以及后期的反复变更。Loma Linda团队把这个现象称为The Incremental Dilemma——递增的困境。

所以Loma Linda项目团队将项目分解成不同的部分，结合大的Coordination Alignment设计周期，在每个时间段给项目不同的部位定义了所需达到的LOD。所以跨越了静态的LOD定义和传统的整体性设计周期，Loma Linda采用了递增的进度管理着项目的设计。

Increment Schedule

在递增的进度下，Loma Linda分析每个专业合适介入到建造中，在最小的付出和对项目的最大影响中找到平衡点。这个平衡点就是开始某项工作的最佳时间点。

付出及影响

逻辑与知识的力量——Design Structure Matrix

Design Structure Matrix 的核心是：任何组成项目的子任务间都是有逻辑相连的，这个逻辑关系本来是杂乱无章的，但是通过矩阵的方式和任务间的从属关系，可以将项目任务进行梳理，从而达到一个最优的流程。所以Design Structure Matrix也叫Dependency Structure Matrix。

我们行业传统的设计流程一般都是自下而上且各专业同时进行，但各专业的同步设计往往带来了协调难的问题。这和施工进度编排是一样的道理：我们往往只留出各专业的作业时间，却忽视了对重叠时间内各专业间交叉作业的控制。设计也是如此，我们一般都是根据大的提资节点来控制设计进度，但对大节点间的专业交叉点很少做到合理控制。BIM的出现让我们有了协同设计，但是协同的过程并没有做到细化到设计元素上的有序，所以我们的设计只是做到了工作上的协同，没有做到流程上的协同。

McCarthy基于DSM理论进行了开发（PS：国外很多学术网站都有免费或者收费的DSM软件，但不一定适合于建筑行业）。利用开发的软件，McCarthy将设计的对象进行编码，每个编号对应一个特定的元素。同时像编排进度计划逻辑关系一样，将每个设计对象所涉及的其他对象从属关系标明。就像进度编排中前置、后置任务一样：完成这个对象的设计之前我需要先解决什么问题，完成这个对象设计之后我才能进行其他什么工作。

设计对象逻辑编排

设计对象从属关系图

各项设计对象间的从属关系编排完后，项目的设计对象就有了逻辑关系，每个编号对应唯一的对象，编号与编号之间有着逻辑思维。

设计对象元素化

但此时的设计逻辑关系是杂乱无序的，我们传统的设计协调大都如左上图所示：有交接没次序，遇到问题再解决，这无形之中降低了我们的协同效率。

借助于DSM理论，McCarthy将设计逻辑矩阵化，通过从属关系重新将最前置设计元素依次筛选出来，形成设计进度以及跟随着进度的所需协调的设计对象。

DSM矩阵表梳理设计逻辑

DSM矩阵表优化后的设计逻辑

McCarthy通过同样的方法，对各个专业的设计对象进行编号，同时梳理出各专业间相互的逻辑关系，通过DSM对设计先后性进行优化，并根据优化后的设计矩阵表制定出相应的设计计划，同时进行设计协调及碰撞检测。

Loma Linda设计（属结）从构矩阵

DSM 使Loma Linda项目的整体设计逻辑关系形成了企业显性的知识，为企业未来同类项目的设计实施提供了参照依据。当无数个同类项目的设计逻辑矩阵汇总在一起，这样的逻辑矩阵就像是人的思维神经，未来企业可利用这样的“神经系统”为自己做“思考”寻找出适合本项目的最佳设计路径。

同样，将知识转化成具有逻辑的显性对象，使得未来的设计变更风险大大降低。

DSM设计神经网络

最后再来说下信息

Project Documentation

模型的信息不代表模型里的信息，一个良好并且统一的Project Documentation Structure（项目文档结构，这里可以理解为信息结构）是保证项目信息顺畅传递的基础。其实美国有个优势，因为他们在二维时代设计阶段就有Specification（Specs，国内有时把Specs翻译为技术规格书）和编码体系的概念，在施工阶段，施工单位会顺着编码体系把信息的承载通过Submittal Log延续。BIM技术出现后，美国开始把Specs和模型进行互通。所以目前BIM平台间信息交互的现状并不是困扰美国建设行业的主要问题。

总结

从上面种种手段可以看出，Loma Linda团队完全抛开了行业技术现状的约束，在解决施工无法使用设计模型这一问题时，主体思路是通过从自身的研究出发对传统的流程进行改造，并借助了逻辑与知识的力量，使项目的设计过程尽可能地变的线性，一改以往周而复始的情况，从而确保施工使用设计模型的连续性。

People-Process-Technology

反思Loma Linda团队的实施，我们不难看出，我们常说的技术其实本质都不是技术，这些“技术”的出现只是为了解决某些特定的问题而生成的工具，解决问题的核心其实在于我们自己。我们的行业出现了这样的问题：用解决特定问题的“技术”来解决其他领域的问题，“Technology-Process-People”这样倒置的顺序使我们陷入了incremental dilemma的困境。于是这个困境被不断扩大。而这个困境的始作俑者是我们自身，并不是技术。

我常常反思我们的行业究竟需要什么样的案例来推动我们的进步。我们的同行总是热衷于“高端”，讲述自己做了哪些黑科技，应用了哪些点，在广度越来越大的时候，却往往忽略了背后的深度。Loma Linda的案例只是我们在地球另一端的同行们无数案例中的一个，那里的同行在每个点上越走越深，越来越接近问题的本质，越来越接近未来。