甲方、设计、开发者同台聊，他们都怎么看待BIM和数字化平台？

你好，这里是BIMBOX。

前段时间，我们举办了一场线下沙龙活动，名称是「BIM盒聚变·北京站」，全国各地100多位圈子里的朋友，用一整天时间探讨了很多BIM与数字化的问题。

针对这这些议题，我们分成三期内容，给你做个活动总结。第一个话题的内容回顾请看这里：

因为每个话题的探讨时间都很长，大家不讲PPT，台上台下平等交流互动，聊出了不少有价值的内容。我们也把所有共同探讨的问题，做了详实的记录和整理。

经过后期剪辑制作的现场视频全纪录，以及逐字整理、加入了思考与评论的PDF活动内容报告，正在BIMBOX进步学社分三期持续更新，目前视频和报告都更新完了第二期，感兴趣的小伙伴可以扫描下面的二维码，永久观看。

在此特别感谢本次活动的独家赞助商，上海秉匠信息科技有限公司，他们凭借自主研发的「黑洞」引擎，在国内很多数字孪生和智慧城市项目中，为用户的数字化转型提供了解决方案；最新发布的「星云三维数字基础平台」，可以帮助企业可视化、低代码快速搭建自己的BIM+GIS管理平台。

活动的第二个主话题是「工程数字化管理平台，怎么能做出价值来？」话题嘉宾包括：

连云港港口控股集团技术研发中心BIM主任黄洋

中国建筑标准设计研究院有限公司数字化中心主任 何爱利

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

下面就来和你聊聊，甲方、设计方和软件开发方三个不同视角，分别有怎样的观点。

很多企业建设平台砸了不少钱，但除了展示作用，很难体现出价值来，从「数字大屏」到有价值的数字孪生，企业能做些什么？怎样看待工具？

黄洋谈到，以前他们在做数字孪生项目、需要继承工程管理数据的时候，发现要把数据应用起来会面对不少的困难，其中数据质量就是需要突破的问题之一。

比如在档案馆找到已建成项目的档案，发现尽管这些资料有数字版本，但很多都是扫描的格式，里面的数据是没办法直接调用的。

和同行交流的时候他也发现，很多企业目前这个阶段其实并没有很重视自己的数字资产，尤其是没有被一线的施工员、甚至项目经理所重视。

黄洋认为，数字化转型首先需要一套适应企业流程的项目管理工具，要让这个工具适应企业，而不是让企业去适应工具，因为想改变企业自身管理习惯是一个超出技术层面的问题。

第二就是有配套的管理机制，要有顶层设计，尤其对于央企国企类型的单位。我们最终使用的工具，相当于是内部管理流程的一个物化结果，从一个比较虚的管理学，变成了一个可以实实在在操作的工具。

最重要的是所有参与者的认知，这往往需要通过管理模式的提升才能达到，很多时候平台使用者抱怨平台不好用，一方面可能真的是平台的问题，另一方面，可能是参与者内心就很抵触这种工作方式，让参与者接受并融入这种工作模式，是最重要的。

夏海兵也认同，从数字大屏到数字孪生，不仅仅是一个工具的形式，而是要把生产的流程和业务管理的流程都升级再造，如果工具变了，但流程还是传统的业务管理流程，是没有办法产生复利和价值的。

行业之所以存在「两张皮」的问题，就是因为大家在用新瓶子装旧酒，工具是提高了流程改造的上限，但改造还要从企业本身抓起来。

在平台开发方面，夏海兵建议多去考虑给不同参与方不同的功能界面。

一个工程里，有甲方、设计方、施工方、监理方，还有各种咨询方，往往他们的数据源是同一个，但不同的角色对数据的颗粒度要求是不一样的。那么如果这些人登录到一个平台，面对的界面和数据都是一样的，这种平台反倒会增加大家的工作量。

秉匠曾经做了一个「千人千面」的平台，能根据角色的不同，只推给你需要的数据，对于你的业务逻辑，软件只为你提供特定的操作界面。

往往设计方、施工方比软件商更懂业务，那么这样的多界面设计就应该交给他们来完成，软件商可以帮助他们解决底层基础的搭建。

比如他们做的「星云」就是一个可配置的基础平台，行业里也叫零代码开发平台，交付到设计院或者施工方手里，对方再根据自己不同的项目、不同的角色和不同的管理流程，对前端的功能和表单做不同的配置。

何爱利谈到，如果「数字大屏」唯一的作用是给领导的决策提供指导，而不能给员工带来价值，反倒给他们添麻烦，这样的情况多了，人们就会对BIM和数字化产生抵触的情绪。平台建设必须考虑一线人员的工作量问题。

他们自己也建设了数字化管理平台，整个流程是分三步来推进的。

第一步是整个业务流程的标准化，统一不同团队项目管理各自的「特色」，去掉那些影响流程的人为因素。

第二步是通过和BIM技术的结合，把标准化的业务流程数字化，原来的流程都是一个个的表单，数据在表单里流转，现在是做了一个底层的数据字典，对于每个参与管理的角色，定义一个组织架构的规范，让每个角色有清晰的工作职责。

第三步是做流程工具化，把数字大屏背后的管理行为深入到每一个项目管理人员。

实际上，工作推进到第三步压力还是很大的。因为这些流程和工具比较容易受到一线人员的抵制，传统工作方法他们已经很熟悉了，新的流程必然要带来新的工作量和学习成本，一线人员会觉得你在给我添麻烦，又没有让我的收入提高。

所以在做工具化的过程中，必须要考虑的是减少一线人员的工作量。比如流程中大家都要填写很多次项目名称，如果不要求统一，平台就识别不了，要求统一填写，工作量就会增加。

发现这个问题之后，他们就在平台上做了功能，只在初始节点填报的时候需要手动输入项目名称，其余的环节大家都是直接引用这个名称，这样大家不用反复填写校对，也会节省管理人员的时间。

BIMBOX认为，管理流程的梳理、把梳理好的业务流程标准化、数字化，这是建设平台必备的前置步骤，数字化不是目的，而是手段，它到底用来帮助解决什么问题？这些问题不通过数字化手段是怎样解决的？数字化带来哪些具体的改变？

这些问题坐在那是想不出来的，要和人交流，要去琢磨那些具体又杂乱的事儿，一线的意见在这里非常重要。

当我们交付产品的时候，无论是一套信息模型、一个数字孪生成果、还是一套软件，往往都会陷入这样的思维陷阱：我都是为了你好。

为了你好，你就要忍受它目前不太好用，要忍受工作量的增加，这与其说是理想主义，不如说是站在产品端的自我欣赏。需求来自用户，而产品方的全部价值，就是替用户减少了多少麻烦，如果用户不欢迎你，那大概率是你带来的麻烦比解决的要多。

何爱利也谈到了软件和流程的关系，她认为流程梳理一定要由懂业务的人来做，他们也会拉着整个工作组来做这件事，不停地问他们需要的流程是什么样的。

她觉得数字化转型的第一步，不一定要改变流程，而是先顺应流程，因为人家的非数字化流程发展了这么多年，已经非常熟悉了，一下子就改变和颠覆是不现实的。

在一个项目里，他们和秉匠科技合作，主要是因为他们能提供一个这样的流程快速配置方法，因为平台要给一线人员用，所以就要通过快速配置、快速迭代的方式，来切实地满足一线人员的需求。

在这个过程中他们会走访很多的一线人员，和他们沟通需求，甚至字体大小都需要给配置好，像这样的细节功夫会下很多。这时候每次修改不需要重新写代码去开发，用配置的方式就能很及时地跟进满足这些需求。

说到底，要做出来一线人员真正愿意用的、减轻他们工作量的工具，让他们觉得你是尊重他们的需求，而不是来折腾他们的。前期要做很多这种看不见的底层数据工作，很多时候要从数据字典、数据标准开始做，等到最终的工具层，反倒是比较省力的阶段了。

黄洋还补充到，他认为是软件适应流程，还是流程适应软件，也得看用户的现有管理水平。

像是何爱利和夏海兵提到的这类项目，交付的对象如果是中建、中铁这样管理水平比较高的企业，效果会是比较好的。

一些单位，可能已经习惯了自己的流程，管理水平也确实不高，很多流程和决定是基层领导拍脑袋，那就不能是平台顺着流程走，而是先要做流程再造。

站在服务的业主的角度，项目要提质增效，就要把传统的、低水平的管理模式改掉，当然这样的项目做起来难度就会比较大。

这种情况需要用到人的沟通能力，跟项目部开会的时候，他们会反复强调数字化参与过程尽量不增加他们的工作量，和集团领导开会的时候，就会说这个事是对我们集团建设板块有意义的、具有战略价值的，是建设板块健康发展的重要支撑，也是建设板块未来核心竞争力的一部分。

数字化系统相比传统的方式效率会提升，这里说的是整体效率提升，对于基层来说可能还是不理解，会不愿意配合，那就只能是通过满足一些需求来引导他们，这也是一个需要逐渐适应的过程。

除了用于内部管理的数字孪生，再谈谈销售型的数字孪生，也就是那种以软件、平台、运维工具等形式，对外输出，在传统的项目交付之外单独产生盈利，这条路该怎么走？

这个话题很有意思，三位嘉宾从他们各自的视角谈到了怎样在项目中去满足和挖掘需求。

夏海兵谈到，他们做技术服务、接触用户需求的时候，会碰到一些远远超过目前技术水平的需求。

比如大家在做管理平台的时候，现场的进度需要跟模型进行绑定，里面要涉及一些手动绑定的工作量，这时候客户就会问他们，能不能把这个工作量降低到零，这件事在当前的技术水平下就是不现实的，我们的能力边界是让这件事的工作量降低，但没办法变成零。

怎么降低工作量呢？可以通过编码，如果信息化编码水平做得比较高的话，那可以把分部分项的编码植入到构件里面去，这样可以在过程中减少大量的人工操作。

他们在上海的一个路桥项目中，就做了三码合一的工作，这么做也是基于甲方的需求，降低模型挂接信息的工作量，但这个编码的过程是不能省去的。

再比如，在出来创业之前，他参与了一个上海地铁站的运维管理，里面有一些运维厂商也在做服务。

这里面的问题是，地铁站里面涉及20多个专业，每个专业都有自己的管理平台，但地铁运营方需要一个总的平台，把这20多个专业的信息都汇总到一起，要让车站管理人员以一个上帝视角来掌控全局。

一旦数据的维度多了，会更便于决策，当然这个决策支撑并不是由开发商来做的，而是运维单位要有一套服务于决策的算法，也就是有了这些多维度的数据之后，怎么基于它们去做精准的预测，或者说判断当前的某些设备存在问题，那么原来的系统因为数据的维度不够，也是做不到的。

这么多维度的数据，这么多的算法服务，汇集到一起，数据的体量就非常大，就需要一个超强的数据承载底座，把这些数据流畅地结合到一起，还能方便地随用随取。

此外，还需要考虑多种数据的接口，因为每个专业都有和物联网相关的系统，把它们打通、服务于业务也是存在不小的难度。

信息集中、方便批量搜索调用，在加上多种数据接口，这几个要求取个交集，就是传统运维手段很难满足的领域了。

反过来今天我们使用基于BIM的三维平台，在解决旧麻烦的同时，也会带来新的麻烦，比如三维数据对数据底座的承载能力要求很高。这也是他出来创业做「黑洞」引擎主要解决的问题之一。

另外，时间成本和研发成本也是必须要考虑的因素。他们利用引擎帮助很多企业做了定制化的平台开发，麻烦就在于每个平台都要从零开始研发，投入的成本很高。

工程行业一旦签订了合同，甲方就需要你在最短的时间完成开发和交付，效率不变的前提下，短期「压」出来的产品肯定是效果不太好，可能连调BUG的时间都不够。

以前开发者精力要花在前期调研、需求整理、做原型、写代码、做测试，可能要几个月的时间，设计院和小公司根本不可能抗住这样的时间和成本。

于是他们又在黑洞的基础上，开发了一个工程行业的低代码开发平台，名字叫「星云」。它把「黑洞」的三维图形引擎能力都包含到了「星云」里，这样三维部分的研发工作就省下来了，再加上前面说到的，基于业务的快速流程配置，也省去了大量的业务代码开发。

这样当有一个项目需要上平台，开发者主要考虑的问题，是把项目的管理流程和业务表单梳理清楚，两三个人就能快速完成交付，在项目推进的过程中，遇到甲方的新需求、模型数据变更等问题，用低代码平台也可以随时快速响应。

黄洋所在集团的主营业务是交通运输，基础设施建设也是围绕服务港口交通运输展开的，他讲到了这样一个例子。

在疫情期间，港口是封闭管理，车辆从高速公路下来进港口，车门上是要贴封条的，这个过程如果封上的时间太长，司机在车里呆着受不了，所以就要尽量缩短车辆在港口停留的时间，最快的把集装箱卸下来让车开走，这就是一个典型的需求。

还有个需求，装着集装箱的车辆轨迹，需要上报到集团的后台系统，还要和生产系统对接，车辆一进港口，司机自己扫描二维码申报，系统后台就知道这个集装箱要到什么位置去，给司机规划好路线。

此外对车辆还有监管的需求，所有车辆在港口里的路线不能离开控制的区域，这在平台上对应的功能就是电子围栏，超出范围能自动报警。

以往是有的公司做了设备管理平台，另外一个公司做了个智慧工地平台，还有运输公司、环保公司等等，也需要采集自己的数据。如果每个公司都搞自己的平台，那领导就要打开很多个不同的平台，非常的麻烦。

这时候一个统一的数字大屏的意义就出来了，我们可以把不同公司的信息汇总到一起，和以前单纯的可视化展示不一样，可以去进行一些互动性的操作。比如有地方报警了，领导收到报警点一下批示，就可以在OA系统里形成一系列的任务流程，分配到下面的分子公司去。

他们在里面扮演的角色，就是把领导的想法与现场的业务需求结合起来，找一个平衡点，这个所谓的平衡点，就是在不花太大代价的情况下，尽可能满足大家的需求。

另外，在他们的项目中，也会遇到夏海兵所说的情况，领导提出一些现阶段技术没法满足的要求，比如要求平台上加一个在线会议系统，还要有项目自动巡视功能。

他的做法不是马上去质疑领导需求的合理性，而是往深处去思考，为什么需要这些功能，能不能用其他手段去满足。港区面积非常大，如果领导下去检查可能每天只能看一两个项目，时间全花在路上了，非常低效。

于是他们就思考，是不是可以做一个项目可视化交流平台，同时又把三维平台的功能也集成上去。然后在项目管理平台里嵌入了摄像头和语音交互系统，再把音频、视频和项目管理平台集成到一起，这样领导的需求就基本上满足了。

何爱利讲了一个更贴近大家日常的项目需求：怎样用数字化解决家长接孩子的难题。

这是一家内蒙的小学，他们先是交付了BIM模型，对方不会看；后来通过数字平台交付了一个能更容易查看模型的成果，但尽管已经比直接用建模软件简单了，客户也还是不用，觉得这个场地不大，溜达一圈也就几千平方米，干嘛要看模型呢？

后来经过沟通，他们又做了一个「平战兼用」的智慧管理平台，就是两条路线同时走。

第一条是给人防办做整个人防设施设备的管理、空间的管理，这些设备通过物联网设备采集的信息，保证设备的正常运行。

另一条是给学校平时用的，解决了校方的大麻烦。这个学校有一条特别狭窄的路，基本上到了上学和放学的时间，这条路都会彻底堵死。

他们在平台上做了一个功能叫「智能接送」，在地下空间做了六个闸机口，每个闸机口的间距有1.5米，然后做了一条很长的学生通道。平台靠人脸识别知道某个时段哪个小孩放学进入到地下空间，然后把信息自动发送到家长的手机上。

为了避免拥堵，他们设计了一个开放的公共停车区，家长的车到了接送区，平台会识别车牌号，如果孩子还没有放学，就会在大屏幕上通知家长到停车区等候。

因为内蒙的冬天是很冷的，不能让孩子在外面冻坏了，所以如果孩子先放了学，家长的车还没到，他们还在地下设计了一个儿童活动等候区，冬天不冷，等平台识别到家长的车来了，再广播通知孩子去闸机口。

还有一些细节，比如家长很关心地下小孩等候区的空气品质，那他们就做一套室内环境品质的监测系统，保证孩子在等候的时候是在一个空气质量很好的环境。

这只是平台应用其中一个例子，他们还做了很多辅助学校管理的应用，把模型和数据拆解，交付给人防办、学校和家长，变成和他们生活工作相关的应用场景，何爱利认为，这样的数字化平台才是有价值的平台。

BIMBOX认为，几位嘉宾分享的案例都非常有意思，很多时候我们可以去和同行抄作业，比如大体的技术路线、管理上的避坑，但你有没有发现，到了真实的业务场景，抄作业就不好用了。无论是学校家长接孩子的需求、建造过程中绑定进度信息的需求，还是港口车辆监管的需求，都是发生在特定企业、特定人员，甚至是特定时间内的。

当你的用户没有这些需求，而你又提供了大量的服务，对他们来说，就是没必要的瞎折腾，无论你使用的是多么高端的技术。

而更难的是，往往客户的真实需求在很浅的沟通中并不会告诉你，可能是他还不信任你，也可能是他自己也没想过数字化有可能解决这些问题。

扎到一线去，裤腿上带泥，需求这东西，真的只能是一点一点地唠出来。

但反过来，看其他人的案例，至少可以帮我们打开一些思路，了解一下别人在使用什么技术应用点，思考一下有没有可能平移到其他服务中。

接送孩子的人脸识别，能不能用到酒店客户管理？港口车牌识别和路径规划，能不能用到装配式工厂的运输管理去？低代码的服务，能不能被我用到新的项目范式里去？

对这些问题的发散思考，或许能给未来的项目落地带来不小的价值。