对BIM运维的理解与应用现状 BIM运维管理通常被理解为:运用BIM技术与运营维护管理系统相结合,对建筑的空间、设备资产进行科学管理,对可能发生的灾害进行预防,降低运营维护成本。在具体的实现技术上往往会联合物联网技术、云计算技术等等,通常将BIM模型、运维系统与RFID、移动终端等结合起来应用。最终实现了诸如设备运行管理、能源管理、安保系统、租户管理等应用。 我想,这一理解本身并没有什么问题,甚至围绕这一理解衍生出的许多类似的在运维阶段的BIM应用已经层出不穷——至少是概念已经被炒作得满天飞了。运用这一套概念去忽悠业主(特别是不少大型公建的业主),让其为BIM买了单,但实际实施的时候业主只得到了一个“毫无用处”的BIM模型(还不能保证这个模型与建筑实体的一致性)或者一套基本不能实施的所谓“BIM运维系统”,像这样的事例我相信在目前的中国BIM市场上还真不少见。实际上我并不怀疑这一运维应用体系的可实现性,我相信从技术的角度来看这些应用都早已不是问题。但是目前国内BIM在运维中的应用案例并不多,宣称自己成功应用的就更是寥寥可数了。 基于这样一种现状,那么我们不经要问了,到底问题出在那里呢?是什么因素阻碍了BIM在运维阶段的成功应用? 可能存在的问题 我并不敢断言造成BIM运维应用的效果不佳的原因,权当斗胆揣测,以下几点,算是抛砖引玉: BIM运维的价值点在那里? 这个问题目前其实并没有得到真正的回答,没有价值或者价值低于对应的付出就没有人愿意为之买单。我知道有不少单位为了寻找到这一价值点也都做了不少探索,发现要实现BIM的某一应用会付出巨大的代价,但是相应的产出却寥寥可数,最后做出来的东西像是某种“昂贵的玩具”,除了用于对外宣传和向上级汇报,并没有多大的实际价值,日常运维还是用传统的方式在完成。这一问题在施工过程中也容易出现,往往导致了BIM应用和施工过程是毫不相关的两条线的尴尬局面。 没有成熟的BIM运维市场环境 BIM在国内的兴起是从设计行业开始的,后来开始逐渐扩展到施工阶段。究其原因,无非是设计领域离BIM的源头——BIM模型最近,BIM建模软件比较容易上手,建模(最开始只是翻模)也相对简单,到了后面施工阶段发现应用起来说概念容易实际落地难,涉及的领域也更广,协同配合难度也更大,正所谓“建模型容易用模型难”。进一步延伸到运维阶段的BIM应用体现得就更明显,实施困难就更大,因为运维阶段往往周期更长,涉及参与方更多更杂,现存可借鉴经验更少(包括国外)。造成这种局面的原因很多,但是整体的BIM应用市场不成熟可谓重要原因之一。整体市场不成熟——没有相应的指导性规范,没有成体系的匹配型实施人才,没有明确的责权利细分规则,没有市场角色定位,更没有相关的市场运营机制,这就在所难免的导致了该市场的混乱,主要表现在价格的混乱、角色的混乱、责权利的混乱等等,整个市场鱼龙混杂,故意扰乱市场者比比皆是。短期来看这让不少真正有心从事BIM领域的企业遭受重创,长期来看这又是整个BIM的发展不得不经历的阶段。我们只能说BIM还有很长的路要走。 没有清晰的商业模式 BIM在运维阶段的应用到底是由专业服务公司运作还是业主自我运作?BIM运维与传统物业的利益关系链条如何搭接?如何明确BIM运维的投入产出模式与周期?……类似于这样的问题还很多,都是与BIM在运维阶段的应用的商业模式相关。这个问题本该是在BIM应用前考虑清楚的,但是这一点往往被大多数探索BIM运维的企业所忽视,但是却在关键的时候限制了BIM的实施。 除了以上几点以外的其他原因我们都已经有过了深入的讨论,我这里不再赘述。 另一种BIM运维思路 “为什么要用BIM?” 这可能是每一个试图应用BIM的企业和项目都会考虑的问题。得到的答案可能根据实际情况不同而各种各样,但是我相信大多数是类似于“碰撞检查”、“综合优化”、“虚拟施工”等等这样的直接指向BIM在设计或者施工中的应用点上。原因很简单,我之所以用BIM就是因为我有直接的想解决某一问题的需求。(这已经算是不错的出发点了,实际上有大部分企业是在根本不知道BIM能解决自己什么问题的情况之下就抱着试一试的心态开始应用的,这样做得到的结果实际上是可想而知的——收获寥寥。) 对BIM技术的发展有所把握的话都会明白,为施工单位提供一个没有碰撞,已做好综合优化的BIM模型实际上是对设计单位的基本要求,是设计单位的份内之事,并不应该成为某项单独应用而独立取费;以翻模为基础,并且还只会做碰撞检查、综合优化以及其他附加值较低的服务的咨询企业应该在不久的将来会被淘汰。把“虚拟施工”、“工序模拟”以及“实时漫游”这一类应用真正做成“优化”而不是“动画”的可能在国内还很难找出几家。 所以我觉得以解决设计和施工中的具体问题作为选择采用BIM技术的做法从出发点上来看就错了。我个人觉得BIM应用的出发点应该从运维入手。这种思路体现在做BIM的根本出发点都是为了解决运维过程中的某一具体问题,为了达到解决这一运维中的问题而制定一套完整的实施方案(如有必要则应该包括较为清晰的商业模式),并且将这一方案前置到设计阶段,根据运维的需要而在设计和施工阶段对BIM模型或者相关数据库做针对性的要求,例如我们在运维阶段需要某种参数或信息,则要求设计单位和施工单位在对应阶段就针对性的植入参数或信息接口。而不是目前我们面对的情况:拿到一个BIM模型,不知道它能做什么,真要拿来做某项应用时才发现它又什么都做不了,因为缺少相关的参数甚至模型深度都达不到要求。 第一种实现方式是分步走,第一步的BIM应用可能并不能实现运维的应用但是以运维的要求实施,最后得到了一个可以做运维应用的BIM模型或者数据库。第二步才是做BIM运维。可能第一步与第二步并不衔接,第一步完成后等到实施第二步的市场环境成熟了再实施。例如做别墅项目的“高端物业”或者“智能管家”,甚至将这一平台扩大化到群社网络等领域去,但是这一市场可能并不成熟,那么我们便先实施第一步,先得到一个具有相关数据接口和达到相关深度的BIM模型,积累基础数据,等到成熟的时候再实施第二步。又例如商业中心的智能导购或者旅游景点的智能导游等等局限于精确的室内导航技术瓶颈的都适用于此类。 第二种实现方式是一步到位。这一类项目必须要有明确的运维目标和可实现途径,例如酒店运维、医院运维、交通枢纽运维等等,BIM运维可能只是这些具体运维中的一个小项,比如只做酒店运维的设备一体化管理,BIM运维以实现这一功能为目标。实现这一目标的内在要求就是必须是一个与建筑实体一致的没有碰撞的BIM模型。 这一思路的局限性在于其适用范围上,并不是所有项目都需要做BIM运维,特别是BIM的实施方不是业主而是设计单位或者施工方的时候。 $ K: _* D- H. v
来源:筑龙博客5 R, s) @$ O! ^; ^! B# H% ~! Q- f
% x* U0 v0 q. O5 Q5 [$ Q8 ^- e
X+ H* t8 z& \* l/ g1 z; u; [ |