尊敬的用户，您还未登录，登录之后更精彩！

首页 » 见闻眼界 » 正文
见闻眼界 观点

关于BIM和数字化，100多人在北京聊了12个话题

你好，这里是BIMBOX。
5月13日，我们在北京举办了一场「BIM盒聚变」线下沙龙活动，邀请了来自全国各地的100多位行业朋友，以及7位嘉宾，从早到晚，一起探讨了三个数字化相关的核心话题，和几十个大家关注的小话题。
和一般听演讲、拍照片的行业会议不同，「盒聚变」秉承的思想是，不讲PPT、不画饼、不谈概念，人人平等、内容优先，一切交流全部基于现场深度对话，大家只聊最关注的话题和心里的真话。
这次活动的赞助商，同时也是活动的联合发起人，是上海秉匠信息科技有限公司，他们凭借自主研发的「黑洞」引擎，在国内很多数字孪生和智慧城市项目中，为用户的数字化转型提供了解决方案，在现场也给大家演示了黑洞引擎在项目中的强大功能和实际案例。
我们也非常开心地邀请到了秉匠科技的创始人兼CEO夏海兵，作为7位嘉宾之一，来到现场和小伙伴们真诚交流他在行业中的见闻，以及他对工程行业数字化进程中遇到那些问题的思考。
这次的活动内容非常的「扎实」，从上午10点一直到晚上11点，大家午餐和晚餐也都聚在一起，不停探讨问题。来参加的朋友说：「以前参加活动，到下午两三点人就走一半了，这次聊了十几个小时还没聊够」。
活动一共分成了三个大的主题，分别是：
➤ 各方数据难融合，数字化转型怎么转？
➤ 工程数字化管理平台，怎么能做出价值来？
➤ 区域和城市管理，数字化怎样进入2.0？
每个话题的探讨时间都很长，大家在主题内容之外，也临场发挥了很多其他与BIM、数字化相关的提问与回答。
这样高密度的思想碰撞，当然产出了不少成果，我们把所有共同探讨的问题，做了详实的记录和整理，留存下来给没能参加的朋友们做一个参考。
经过后期剪辑制作的现场视频全纪录，以及经过我们逐字整理、加入了思考与评论的PDF活动内容报告，正在BIMBOX进步学社分三期持续更新，目前视频和报告都更新完了第一期，感兴趣的小伙伴可以扫描下面的二维码，永久观看。
同样，我们也会分上、中、下三期内容，以相对简短的方式，帮你快速梳理一下，每个话题下大家都聊了哪些东西，今天就是三期内容的第一期。

BIMBOX「盒聚变」主题分享

分享人：BIMBOX孙彬
「盒聚变」是什么意思呢？「盒」代表BIMBOX发起，「聚」代表人与人聚在一起，「变」代表给每个人带来未知的机遇。
「盒聚变」还取意于它的谐音词「核聚变」——每一个漂浮在宇宙中的原子，都显得孤独无力，当有机会让它们彼此靠得足够近，就能彼此融合碰撞，释放出巨大的能量。
在我们的进步学社里，每个人背后都有值得学习的故事和思考，同样今天来到这儿的每个人，也都带着自己不同的故事，就像会场的墙上那句话：当你无法坚持的时候，不妨找一群人试一试。
今年我们观察到咱们的行业正在悄悄发生着两个变化，第一个变化总结成：「大BIM、数字化」。
并不是说以前的「小BIM」大家不做了，而是关于BIM的模型应用点，大家已经探索的差不多了，哪些有价值、哪些是空话也比较清晰了，那接下来数字化这个东西往哪走，能不能跟BIM很好地结合起来，成为了更多企业正在探讨的问题。
第二个观察到的变化总结成五个字：「业务基本面」。
往前看几年，你发现无论是搞民建的、搞水电的、搞路桥的，或者同一个项目里搞机电、建筑和结构的，大家谈论的BIM差不多，但这两年情况变了，当你和一个人谈论技术的时候，首先得问你们具体是做什么业务的？
也正是因为大家探讨的业务话题浮出了水面，也让我们更需要认真去听、去思考，去分辨每个技术方法的局限性，别人的砒霜，或许是你的蜜糖，反过来也可能是这样。
查理·芒格说，宏观是我们没办法左右的，无论是国际上的还是国内的市场情况，我们都必须接受、没什么好抱怨的；而我们可以做、可以出成绩的地方，恰恰是在微观的地方，在具体的细分领域中。

各方数据难融合，数字化转型怎么转？

话题嘉宾：

华东建筑设计研究院数字化建筑设计研究中心主任 余飞

广西交通设计集团有限公司IT总监兼数字交通设计院院长 王长海

上海秉匠信息科技有限公司 创始人兼CEO 夏海兵

这个话题下，现场的朋友和嘉宾一共聊了12个问题，篇幅原因没办法全部展开，我们选了其中的6个话题，给你总结一下大家的核心观点，所有问题展开的内容，你可以去完整的报告和视频里学习一下。
1. 目前工程行业的数字化转型，要把多源异构的数据，比如BIM数据、GIS数据、IoT设备采集数据等等，都融合到一个平台处理，以便释放出更多的价值，应该怎样来做这件事？
作为开场的话题，三位嘉宾分别结合个人的职业成长和发展经历，谈了自己的观点。
余飞谈到，一开始设计往往只需要几何数据，随着项目的推进，各方的需求也会加入进来，甚至政府管理层也会介入，于是开始有了后面各种各样的数据需求。
当我要实现某个业务场景的时候，就必须融合它所需要的数据类型。
他认为这里面标准化的作用非常重要，并不是说我们写一本标准，定了很多录入的规矩，就是标准化，而是说在各个环节、各个场景，它使用的需求界面是怎样划分的。
这里说的「界面」，不是指软件的操作界面，而是代表各方在使用这个平台的时候，到底是那一块的数据能给他带来价值的具体场景。
实际上这样的工作已经超出了设计院本身工作的范畴，设计企业只关注自己的设计界面，包括建筑、结构、机电等专业。而在一个完整的项目里，还有投资界面，管理界面，施工界面，运营维护界面等等，它的分界是非常复杂的，根本不是说我们靠一个简单的编码，就能完成所有数据的转换。
余飞所谈到的「界面」，是对「场景」一词，向着更可操作性的方向做出的延伸，有些类似我们使用软件的「云」和「端」的情景，后台有一套统一的数据，前台则是根据不同的使用者和需求，提供不同的操作流程。
这意味着在传统设计到BIM设计，再向数字化发展的过程中，有两个非常重要的飞越过程，第一层是「做加法」，把全量的数据备在后台；第二层是做减法，把部分数据通过不同界面提供给不同的使用方。
王长海谈到，到了上层，项目需要数据的集成和融合，这里又会分为松的耦合与紧的耦合。
比如BIM标准、统一的IFC编码，就属于紧的耦合，大家希望利用一个模型把这些耦合的数据传递下去，从勘察设计一直延伸到施工建设、管理运营。
另外还有一种松的耦合，典型的就是数据库，它是一种规范的格式，我们的目标是把它做结构化处理，给出不同的字段，把同一个对象在不同侧面描述出来。
紧耦合可以利用设计工具的结构化数据，而松耦合包括一些属性信息、摄像头监控数据、现场工人填报的数据等等，都要用非结构化的方式去解决。
他本人在电力建筑、交通行业和基础设施行业做了近 20年，工作历程基本上就是从纯设计角度演变到丰富的业务角度，从追求数据的结构化延伸到解决非结构化数据的一个历程。
他所谈到的话题，也体现了从BIM到数字化的一个跨越——从紧耦合的、结构化的、逐条附着在模型上的数据，到松耦合的、非结构化的、依赖平台而不是建模软件的数据。后者往往需要独立的设计和开发。
夏海兵站在开发者的视角讲了自己的故事。光是简单的几何数据，在图形引擎里就要解决精确性和算力平衡的问题，到了工程的设计和施工领域，又会加进来很多的非几何数据，体量比较大的项目还会遇到GIS数据、点云数据、倾斜摄影等等数据。
这里最难的问题在于，把它们都解析成一种数据格式，还要保持流畅。在出来创业之前，他在上海接触了很多地铁项目，需要把非常大体量的、多个专业的数据汇集到一起，也通过建立联盟、联合多家公司统一标准的方式来解决模型数据库的问题。
后来发现数据量大了之后，高配的电脑跑起来也会非常卡，所以他找到了联合创始人，一起出来想办法解决这个事情。从几何数据到非几何数据，从单平台到跨平台，核心的目标就是把不同的数据解析到同一种格式，关键还要快。而这也就是黑洞引擎诞生的过程。
企业选择不同的平台作为数据承载的底座，走研发路线还是采购路线？里面有哪些值得关注的地方？
余飞谈到，对他们来说，在当前的阶段，选择的路线是多平台集成，哪些数据在这个平台里的效率最高，就选择这个平台，同时保证这个平台的数据可以传递到下一个平台，而不是在功能上执着于All in One。
考量平台的几个重要参考，分别是性价比、数据自主性、数据安全和是否国产。
夏海兵很同意不要All in One的观点，他们的一些客户在做数据大屏的时候会选择渲染效果好的平台，而到了具体的业务层面，则是选择一个效果不那么好看，但是效率非常高的平台。目前没有看到一家公司，能把行业所有的业务问题都解决，还是要博采众长。
两位分享的观点，或许是一种历史阶段性的妥协，同时也是明智的妥协。
既然不All in one，各家企业的决策和选择也就显得尤为重要，哪些功能采购通用工具？哪些部分外包开发？哪些部分要自主研发？以及这些数据该怎样打通？如果不能全部打通，那么哪些是可以暂时妥协的、哪些是决不能妥协的，这些都非常考验数字化转型企业对自身业务和实际情况的理解，是决不能抄作业的，最终也会决定一家企业转型的水平和成果。
王长海则是说，交通行业在平台选择上非常注重聚焦解决问题，地质地形、结构、洞口造型、隧道跟随山形地势的变化等等，也取得了不错的收效。
一方面因为技术还不够成熟，机会还很多，一方面是技术不能大而化之，要聚焦到具体问题，最终得出的结论还是要拥抱变化。在动态的变化中找到道路，等到变化结束了，人也就没机会了。
在一家公司，领导看的是远处，那必然看得很模糊，缺少细节；一线人员看的是脚下，细节的问题很多，同时也很难关注远方的风景。
而在「宏观」和「微观」之间，还存在一层「中观」的视角，也就是这里谈到的「聚焦于具体问题」，向下懂技术细节和解决方案，向上能承接高层的发展方向、帮助制定可执行的规划，这恰恰是中层管理人员最能体现个人价值的所在。
对于传统企业，比如设计院，自己搞开发这件事，各位怎么看？
王长海认为，传统公司千万不要把自己做成软件公司。设计单位要紧紧围绕着自己原来主要的能力，也就是对专业深度理解的能力，不要把自己做成软件公司，行业里大家要各司其职。
但这并不代表设计院不去做一些开发工作。比如可以适当用一些编程工作，重新组织原来的流程，把它们形成工具封装在一起，更快的把出图这件事完成。
但是去开发什么，这点一定要想好，我认为不应该从底层的图形引擎这类工具开始做起，甚至有的企业连平台都不需要做。
对于大多数企业来说，可以把开发聚焦在应用层，去做最后一公里的打通，这是软件公司做不了的事情。
余飞认为，三维技术其实是给传统企业在红海里打开了一个口子，但传统企业致命的问题就在于，对IT行业不了解，很多设计院都是搞结构的在写代码。深度工具开发的竞争力必然是很弱的。
他认为传统行业一定要做开发，但必须要确定去做哪些应用场景的开发，例如他们内部是提倡，所有比较普适性的功能、那些帮设计师「偷懒」的功能交给软件公司去开发，而提升顶层设计能力的、更不可替代的部分留在自己手里开发。
两位的分享很值得琢磨，现在越来越多的企业都在搞开发、成立研发公司，但很多没有站在产品经理的视角，画清楚自己的能力圈和用户的需求圈，于是发大愿、使大力，造了不少的轮子，结果达到了同级别软件公司产品能力的一半，价格是人家的好几倍，市场化失败的结果可能就是公司解散，一切重来，耽误了数字化转型重要的窗口期。
夏海兵分享到，最后一公里的事情经常要由软件用户自己来做，尤其是专业领域的事，现在CAD和Revit二次开发很多，只要大家别都惦记着自己开发一个底层软件就好。
秉匠除了「黑洞」引擎，现在也做了低代码开发平台，叫「星云」，帮助大家解决开发难度高、代码量大的问题。
比如以前要在引擎上实现一键漫游的功能，要调取很多个接口、写很多行代码才能实现，现在把这个需求封装成一个非常简单的东西，做开发的时候不需要写代码，拖拽、下拉参数设定就可以实现。
作为开发者，他们也非常希望用户这样做，在业务的什么环节用什么功能，满足什么需求，用户自己更了解。
他们还专门在官网上做了开发者中心，把每一个接口具体能实现什么功能呈现出来，用户需要的功能，直接把代码Copy走就可以了。
很多大院做的东西，小公司很难去做到，那么穿平底鞋的普通人、小公司，这条路该怎么走？
余飞说，大院作为国企，在人力和资本方面会占有很多优势，大家会很羡慕，但大型的国企也同样有劣势，很多层级上的行动没有那么灵活和方便。
大公司、小公司都有各自需要面对的问题，最主要的途径还是去做自己擅长的那个细分领域的内容，通过把主营业务做精，去积存自己的产能和资金。
对于管理者最主要的建议是，不能让自己成为这个部门的天花板。
在传统行业里，一个工作10年的设计师面对一个20年的设计师，就得听对方的意见；但数字化行业不是这样，你得鼓励下面任何一个员工。
凡是有年轻人来找他，想尝试一个新东西，他从来不会一巴掌拍死，数字化行业没有人知道确定的答案，唯一的办法就是鼓励、测试。
主动使用新技术，再去看业主对这个新技术的接受程度。如果对方的反响非常不错，就投入更大的精力去培育和发展它，尝试做成收费的模式。
大公司也是一样，一个东西创造出来，也得经过三次、四次甚至更多次项目的滚动迭代验证。
无论是对内培养人，还是对外做项目，都需要借助「PDCA」循环方法，也就是Plan（计划）、Do（执行）、Check（检查）和 Act（处理），在这样的循环往复中，把值得提拔的人才选出来，把值得做的项目做下去。
可视化引擎有端渲染和云渲染两种方案，工地上电脑配置和网络条件都很差，该选择怎样的方案？
夏海兵谈到了一个行业秘密，云渲染最早是游戏公司提出来的，不过需要知道的是，这个策略带来最大的隐性成本是，虽然客户端的要求不高，但服务器的要求是非常高的。游戏公司很有钱，可以搭建配置非常豪华的服务器，但对于工程行业的公司来说，升级服务器的成本可能就会很难承受。
如果在数字化管理平台使用云渲染，比如一个项目需要20个人并发访问，那么服务器的算力就得满足这20个人的需求，如果使用者更多，那需求就更高，所以有时候你会看到本地浏览器没有崩溃，但服务器没响应了。
他们自己不是拼硬件，是用算法来解决问题，比如在上海一家做路桥的公司，一位总工用的是一台没有独立显卡的上网本，但依然可以跑一个很复杂的项目。
网络条件不好，解决方案是做私有化部署，可以直接部署到你自己的笔记本电脑上，甚至部署到你的手机上，这样无论网络怎么样都不影响使用。
作为咨询公司，想请问交通行业有哪些值得分享的案例，比如软件、实施模式、关键点和实现的价值？
王长海分享了几个实际经验。
首先是对内提高效率，拿桥梁来说，先把它做成通用图，解决标准化的问题，然后再把这些通用图做成通用构件；再比如隧道与山体交接的工作量很大，也是用三维设计的方式来提高设计和表达的效率。
第二是把做好的模型对外赋能，除了在设计环节满足自己的需求，也做了编码指南和构件拆分指南，把它们落到项目模型上，对应的就是把设计的模型到施工阶段进行进一步的拆解，把价值往施工环节去延伸，这一点在很多项目上产生了不小的价值。
第三，一部分项目可以继续往下游走，去服务运营管理，很多公路项目的建设投资方同时也是运营方，建造几年时间，运营则要长得多。比如近期在做的一个项目，通车之后会把这个模型重新拆分，比如服务区隧道、特大桥等等，拆分之后往运营和养护的方向去做一些事情。
他也强调，咨询公司和设计院内部部门最大的区别，谈数字化第一要保证盈利，重点就在于对外给别人提供价值，比如同一个模型能不能帮业主控制工程质量安全，能不能让运营更高效、降低运营成本，你要帮人家省钱，人家才会给你钱。
咨询企业去满足他们个性化的需求，这就得我们有人过去驻点，根据需求专门打磨特色的服务，也就是要贴身服务。
软件公司解决前面通用的部分，但你不能买个通用软件、提供通用服务就可以了，真正到了你需要贴身的时候，你要和软件公司的能力区分开，你要懂这个专业、懂信息化，最好能让你的开发团队懂对方的专业需求。
单纯地靠软件提供的服务是很难推进咨询的，而且这个行业的业主都属于长线客户，一旦丧失了信任，再重新建立信任是很难的。
轨道交通这个行业的特点，就是建设之后的运营周期很长，而且涉及到大量的人员流动、安全需求等等，这意味着在运维这个阶段能做的事情非常多，尤其是在安全方面，可能是其他行业不太看重的一个方向，值得重点关注。
王长海说的「贴身服务」是非常值得借鉴思考的一个点。软件公司的生存之道是利用规模化来抵消成本，那么更多地专注于开发普适性的功能，就是软件公司必须的生存之道。而留下的最后一公里，也恰恰是传统企业在数字化项目和服务中的生存空间。
好了，以上就是「BIM盒聚变」上午讨论12个问题的其中6个问题。除此之外，我们还讨论了下面6个问题：

➤ 传统企业怎么看待数字化方面的投入？为了做出改变，需要做哪些事？

➤ 基于BIM的项目汇报，有哪些比较好的新形式？

➤ 目前很多项目没有BIM成果确权的流程，甲方也没有专门付费购买数据，那么BIM过程中、以及最终成果的数据所有权应该归属于谁呢？

➤ 五六十个人做正向设计，面对的个人阻力比较多，请问这件事对个人来讲有什么好处？怎么克服阻力？

➤ 公司很多事都是一个人在推进，很辛苦，很多同事对提高效率不感兴趣、带不动，有什么好的办法？

➤ 数字化转型最后一公里，直白一点问，怎样能产生正向收入？

如果你希望详细展开看看，各位嘉宾在这12个问题中的详细讨论，欢迎扫描下面的二维码，查看活动的剪辑版完整视频和文字报告。
内容目前已更新第一期，报告文字为2万7千字，一共三期，我们会陆续更新到这个专栏里。
有态度，有深度，BIMBOX，咱们下次见！

 

标签： ·

暂无评论

相关推荐

微信扫一扫

微信扫一扫
分享到：

微信扫一扫,分享到朋友圈

关于BIM和数字化，100多人在北京聊了12个话题