实践中什么是BIM这个“理论”问题这样定义还是那样定义，其实并不会影响到我们手头从事的业务，这业务可能是建筑设计，可能是概算预算，或是施工管理，甚至是运营维护。我认为宽泛地讲，满足数字化（未必需要3D、4D），信息中心化并分布式共享，合适的文件权限管理系统这三条的行业内实践，不论是在设计阶段，还是在施工、运维阶段，这种实践都可以称作BIM。

所以你如果是建筑师，从概念设计阶段就着手建立一个项目模型，一开始这个模型也许是SU白模，除了体量和大概的尺寸几乎不包含其他信息。但是你把它置入Google Earth项目基地的位置上，并通过随便什么方式（邮件串，文档协同）与其他项目各方就这这个模型的链接讨论你的创意，这就已经是BIM了

你更进一步，将模型文件放到了你自己的服务器上，给业主开放了一个权限使他可以查看、审阅甚至修改你的草模，这些操作（不管是你自己的操作还是别人的操作）都被系统记录到log里，方便你可以随时查看某一个revision。有了修改操作，系统还会通知各参与方。不同的单位在项目中的角色不同，由此你发给他们的账号权限也各有区别。

某一天你对草模进行了修改，提交保存操作后，系统向业主发去通知：建筑师修改了方案，请审阅并批复，同时向结构工程师发去通知：建筑师修改了方案，请审阅，等待业主批复后修改结构模型。

由于你架空了首层，改变了空间布置，调整了楼层标高，增加了悬挑阳台，立面开了长窗，引入了free flowing space…总之你是实践了新建筑五点，结构工程师登陆你的系统，打开中心文件，看到100+碰撞提醒。他将远程中心文件同步到自己的电脑上，根据变更后的建筑模型，开始修改结构模型：首层你去掉了墙，柱子截面要重新设计；二层你改变了平面布置，可能需要去掉几个柱子，增加几道梁的高度以跨越一个面积增大了的屋子等等，等等；这个结构工程师可能会把重新布置后的结构模型导出为计算分析软件可读的格式，放到计算软件里计算、调整截面，再导回中心文件和建筑模型复核，如此这般几次，总算是清掉了100+的碰撞，他提交了修改，把本地文件与服务器中心文件同步。（这里他只有修改结构构件的权限，其他专业模型不会被修改）

结构师刚一完成同步，那边机电设计师收到系统通知：结构师修改了结构模型，请审阅并修改MEP模型。然后这个机电设计师登陆系统，下载中心文件，根据结构构件的新位置及新的建筑模型，修改风管、水管、电线布置，重新做管线综合，重新设计预留预埋，他可能还需要计算新系统布置的动力情况，做合规性检查等等，等等。他改完了，与中心文件同步，保存…那边的你收到系统通知：结构和机电专业完成碰撞检查并提交了新的design revision，然后结构收到通知：新的楼板开洞，请复核…

好了，你再次登陆系统，发现自己的新建筑五点尝试并没有想象中的那么完美，增大的自由空间面积导致梁高增大，你不得不降低天花标高；之前设想的趣味空间被倒霉的FCU侵占了…你于是在模型上comment到：这个梁太高，我不想降低天花，请想办法改成钢结构；这个FCU占了我的地，请放到别处去，等等。然后其他专业的工程师们就会收到系统通知，如此这般，back and forth，back and forth。

过程虽然令人气馁，但好在任何项目都是这么设计出来的，现在有了BIM这样的工具，你总算不用每次遇到设计协调、变更，都要抓起电话：打开四层平面，看11轴与J轴的那个梁，你要这样这样；你也不用不断地召开设计协调会，把一大堆图纸摊在桌面上，翻得暴土扬长就为了解决一个很小的碰撞问题。你现在可以在一个综合了各专业数据的可视模型上给出自己的意见，通过设置场景让相关人员轻点鼠标就可以被导航到问题的所在；你可以将各专业设计信息汇总到一个中心文件上，追踪历史版本，处理每一个问题，每一个专业的操作都会即时反馈到相关人员那里去。

新工具的出现，催生了新的工作流程，这一流程以我们的经验和理想来看，是一个沟通成本更低，效率更高，差错率更低的流程。我认为设计阶段BIM最突出的优点是在这里。我的这一描述，侧重于各专业间协调，而某个专业受益于BIM的情况，如尺寸驱动，智能捕捉这些，我觉得…这些应用在建筑领域太晚了….制造业早就有了，现在建筑行业当个新玩意来谈得兴起实际有点落伍，不过我们已经开始追赶了不是么。