下载app免费领取会员
本文来源：微信公众号crefm001
2013-11-01
最近几年不断有朋友问：BIM与FM能否打通？时至今日，我这几年间的理解和摸索也够写一点小小的小结了。
0，什么是“打通”？
回答这个问题并不容易，因为这需要小心谨慎的定义问题中所包含的各种基础概念。而对于传统建筑业来说，这实在是太麻烦了，新词、舶来品、新概念太多，还有很多思想是有悖于国内传统认知的。我们先约定：未经定义，不讨论。这样就会减少很多争议。所以本文打算仅讨论这个问题本身。
在这一实例中，当事人也时常说：通了吗？如果还不通，那就继续尝试。这里所谓的“通”的意思是很明确的：从revit软件到FM:Systems软件的数据导出（以及最好是能够双向互操作，当然这要看revit API的授权程度）。对于软件厂商来说，这种通，在内部测试时就已经完成了，用户能不能成功的使用，那是使用的问题，当然也不排除还存在未知的bug。
那么，到底这个打通是一个什么样的对象呢？是像拳头打穿墙体吗，是海底隧道被贯通吗，还是深圳到香港的通道变得快捷了?为了定义这一因素，我们必须要借助其他相关因素才能得到很好的定义。
接下来，我们按照主谓宾、定语修饰语等等的语法因素，来逐一讨论这个问题。
1，什么和什么打通？
在BIM+FM这一表述中，BIM代表了建筑业（的计算机技术），FM代表了物业设施管理行业（的计算机技术），隐含着的两个计算机技术，简单来说就是软件，经常会被省略掉。FM的软件相对比较容易明确，传统的CAFM或新潮的IWMS；而建筑行业的软件可就不容易归纳了，花样繁多，难于在此一一探讨，我们暂且拿两个比较有代表性的来讨论吧，一个是设计建模软件revit，一个是施工管理信息系统vico软件。
如果问题简单到只是：在revit/vico和某种CAFM/IWMS之间对接数据，就像前述的那样，那么显然，已经打通了！
参考：漫谈FMBIM：从Programming到Commissioning
在这里你还会看到不同于BIM到FM的顺序的描述，因为还存在从FM到BIM的顺序。
除了软件之外，如果这两个对象还有其它的所指，比如两个公司的打通或某种神秘的关系的打通，也暂且不在本文讨论之列，本文只打算讨论可以被定义的。
2，打通什么？
承接前述的定义，两个软件之间的打通（对接，导数据，互通，信息协作），我们可以先简单定义为：一个软件将数据送到另外一个。或者再复杂一点：两个软件之间可以互相调取对方的数据。但无论如何，在两个软件之间通的对象只能是数据，即使是某个有形的三维构件形体，它在软件中也只能是一堆数据。当我们把电脑关掉的时候，软件会把所有的三维模型折叠好，收到橱柜里面去，即将数据保存到某个数据库中。
那么，问：经常会有信息的说法是怎么回事？信息和数据有何不同？
在本文的讨论中，两者是一回事。只是在建筑业的专业角度来看，所有的数据都是某种专业信息；而从IT的角度来看，任何信息都是数据而已。我们暂不考虑“数据-信息-知识-智慧”这一序列，虽然这是一个能够更好的区分数据与信息的思考角度，但不适用于本讨论。
这只是定义了一小部分，因为本问题还会衍生出许多问题：FM需要BIM提供什么数据？哪些数据是有用的？需要的数据没有怎么办？前面录入的数据错误怎么办？
于是我们还需要更多的定义。
参考：漫谈系列14 数据
3，谁来打通？
无论是建筑业还是FM，带有主语的讨论都是最有价值的，失去了主语，讨论将很容易变得离散。在房地产开发项目中通常会有多方参与，构成一个围绕特定项目的项目协作团队，这包括开发商、设计公司、施工单位、监理公司、咨询公司等等；而运营则较为明确，有两种可能的主语，即自用物业的FM管理方，与公共物业的物业管理公司（或开发商旗下的物业部门），尽管国内尚无FM专业可言，但由于BIM的风潮引入，使得一批先知先觉的朋友在研究BIM+FM的时候遇到了FM，而少有人去研究BIM+物业这个组合。
但是不幸的是，国内目前所见声称打通了BIM+FM的案例，可能都还没有见到FM、更别说理解了，因为随处可见的乃是物业（而且只是wuye，并非property management）。
参考：漫谈系列13 阶段整合
4，打通了多少？
这是一个由问题2衍生出来的问题，即如果只是数据对接，那么数据导出可能会出现成功率，比如99%的成功率，这既有可能是100次中出现了1次错误，也有可能是指100条数据中有一个是错误的，错误的原因和表现暂且不谈。如果较真的追究这个成功率的数字的话，那还需要进一步定义：数据是什么？是按字节计算，还是一条属性（实质为一个特定字段的一个特定记录），还是一个编码。
至此，我们已经远离建筑业的专业领域，而进入到一个由计算机专业、企业管理（之FM）、项目管理、ERP等领域复合而成的一个新的领域，我们暂定其名为BIM+FM。以我的研究所见，这个领域也许并不存在什么高深莫测的神秘知识，所缺乏的是作为一个单个的探索者而言，其所涉领域之大，难以穷尽，更不用说吃透之后再将它们整合起来了。这实在是力不能支，这是不折不扣的行业级的BIM应用，需要的是一大批人的两两信息协作，而不是单靠一个人去研读资料。这还仅仅是理解这些内容，还谈不上为客户定制解决方案呢！
5，打通了有什么用？
这才是问题的关键！为何要讨论打通，原因是打通了会产生某种较高的附加值，从而令客户买单！
如果是在为一个并不存在的主语服务，或者使用了一个自己也不清楚的软件（的名字），甚或只是声称自己具备某种能力，也许能够一时的忽悠客户、得到订单，但那决不可能变成稳定的商业模式。
6，打通的衍生问题
至此，我们只算是讨论了整个问题的一小部分，而且仅仅是定义。如果我们还想搞出解决方案，那则根本不是本文所能完成的，目前在国内，我相信也极少有人可以做得到。因为我们至少还会遇到下列更为复杂的问题：
（1）倘若选择的FM软件不是CAFM/IWMS系统，而是单机版的小软件，甚或自行开发，那又将会是完全另外两个天地。即使是大型系统，由于FM专业尚未被很好的建立，软件厂商很难于销售，如今年在国内产生的有史以来最大的一宗CAFM采购案例中，大型软件厂商就是如此，I记公司不知道应该如何选择何种软件来匹配客户需求，O记公司的人居然都不知道自家还有此类产品。而这些大型软件公司的销售人员对企业管理信息化领域已经算是谙熟资深了。
（2）单机版的FM软件在国外软件行业正在行将消失，如Autodesk曾经推出的FM-desktop（我们遵照Autodesk内部习惯简称为FMD），Manageengine曾经推出的Facility-desk。这两款软件实则C/S结构，由于数据库市场的变迁，纯以单机版软件内嵌数据库的做法已经不再。大型系统如ARCHIBUS至今仍然保留有古老的C/S结构的产品与B/S并列销售一样，因为他在北美地区的确是有一定的客户群的。但是，前两者后来在全球市场上已经消失，虽然曾经推出过中文版，在中国市场上还未来得及产生过销售记录。
那么国内有没有小型的FM软件呢？完全是空白。倒是如果考虑到物业领域，物业软件有一大批，约有数千种，主要是以小区物业管理为对象开发的系统、单机版软件。
注：本文所述软件均以在国内有中文版、销售支持或有一定的影响力为准则。
（3）自行开发看似更能够贴近客户的需求，但实则难度更大。有两个国内的实例可以说明问题，十年前我在某金融行业的业主方选购ARCHIBUS时，IT部门就进行过自行开发还是采购成熟软件的对比研究，仅ARCHIBUS的三个功能模块（空间，维修，资产。当时的模块划分与今日不太一样，大致上相当于今天的5-7个模块），就需要一个不小的团队开发上三年。最近几年有大型连锁店总部委托开发了一套FM系统，耗费将近千万，却只实现了一小部分满意的功能，即报修维护管理。
（4）自行开发期间遇到的麻烦问题不一而足，尤其是需求工程这一关就极难越过。以我曾经经历过的一个国内的大型交通枢纽项目的BIM+FM开发为例，最初开发团队的当事人对客户的管理组织架构和运行流程无法很好的理解，而客户方又需要进行进一步的优化，理由很简单：如果不能产生优化，那要这些新技术干嘛。而需求工程的源头恰又在与组织架构与业务流程，这是管理信息系统的普遍规律。这个规律非常不同于工程技术领域的单机作业（单兵作战），这种规律的探寻和付诸实施都不是工程技术人员所能够完成的，必须要有足够强的企业管理的背景知识。无需求，无开发，此项目梳理过的需求（已经被规整过，成为解决方案的雏形了）如下：
这种架构的思想不仅来源于企业管理（中的FM），还需要将工程技术与信息化技术（尤其是BIM技术）都纳入进来，统筹考虑。仅仅对这种结构思想的理解就已经是非常困难的事，更何况去实施。
既然已经谈到了组织架构与业务流程，那我们就再往前走一点吧，那就是：FM专业本身到底是什么？
7，FM是什么？
无论我们站在全生命周期的宏观角度，还是建筑项目的实施过程，甚或是一个BIM+FM项目的角度，最终都会遇到这样一个不可逾越的问题，那就是：FM到底是什么？
首先被建筑领域所公认的理解是指运营阶段。在全生命周期角度来看运营是最为漫长的使用阶段，对于建筑项目来说那是终极目标，对于BIM+FM项目来说那可是客户、是预算。比如说数据，运营的数据多从建设过程继承而来，在运营过程中设施工程师查看一台设备的数据，也就是那些设计参数、属性等等，似乎都是建设过程中所能搜集到的，几乎看不到任何技术含量；可能不同的只是，运营所需要的信息分类方式不是施工归档的那样，那是按照建筑工程的规律而做的分类。
那么看起来答案是具有普遍意义的，也就是前述的功能模块图表可以适用于大部分的客户吗？错，全错！这张图仅适用于这家特定的客户，是完全的定制化的个性化的。而且这张图是在沟通过程中被修订了无数个版本中的版本之一。图中的任何一个小格子都有着深切的涵义，全部都是直接指向这个特定客户的特定的管理需求的。
在FM非常成熟的国家的确是有着比较普遍的规律的，比如美国的教育领域，有着几万家教育机构，但凡有着一定空间规模的机构都会有一个FM经理，他们的需求非常接近，那真的可以被归纳为一个体系，从而为之定制开发某种通用型的管理系统，这就是为何美国盛产FM软件公司的最终原因——单一成规模的市场。这在国内还是一个看似遥不可及的梦想，国内的市场还处于“前FM时代”。
至此，我们所探讨的打通BIM与FM的问题已经完全的进入到FM的管理世界了，这不仅告别了建筑业的技术语境，也完全没有了IT的影子，更不用说BIM了。
8，FM与BIM的数据关系是怎样的？
经历了FM的管理世界，再来谈与BIM要打通的CAFM/IWMS就有现实意义了，因为这些软件系统本来就是FM管理体系的信息化。CAFM中的数据就是FM管理作业的数据，按照问题2的定义，互通的内容就是数据的互通，那么我们将会遇到大量的具体的问题，如：
若FM工程师想要添加一个构件，比如是当时施工模型里面没有的一个新采购的设备，他要在BIM模型中添加这个构件吗？还是在CAFM数据库中添加即可？或两边都添加？或一边添加同步到另外一边？或分别添加然后在链接起来？等等。
又如：他如果要修改一个构件的属性信息，将要在Revit这边修改，还是在CAFM那边修改？要构造一个新的中央数据库吗？或是一个由两者共同管辖的同步的数据库？
又如：建筑构件门类复杂多样，而每类属性大异，门窗的十几条属性与空调风口的几十条属性存在很大差异，这在revit这样的软件中可见一斑，因此这类软件都构造了庞大的构件分类编码体系，如UniFormat、MasterFormat和Omniclass三个内置到revit软件的常见体系。那么，之于完全没有这些编码体系的中国来说，需要构造一个新的体系吗？
显然，若无分类体系将构件对象进行分门别类的处理，那数据库将会糟糕到什么程度：一个新增的构件的属性条目（数据库字段）将会高达数千！
现在，为了解决一个数据的添加或修改问题，我们又径直走到了构件分类法（本体论）的领地。研究这类作为行业级的宏观但又极为枯燥的分类编码方法，所需背景知识已全然不再是建筑工程师、设计师、软件工程师之中的单一背景所能涵盖的了，仅仅理解就成为很大的问题、遑论构造一个体系？
内中的理解问题就像前述的软件功能结构一样，拿掉一个小框框、或改一个名字，可以吗？会出什么问题？有什么影响吗？这些问题甚至于没有答案，至少在个人级和团队级应用的层面上没有答案可言，这至少要在行业级层面上才有答案可言。在这个意义上，BIM+FM无疑是行业级的应用。
【陈光 评注】此文写就之后，引发了不少争议。关于BIM+FM的解决方案历来都是争议极多的领域，好在这些文章陆续发出来之后，争议实际上在变少：BIM运维系列文章目录
后来我梳理了三种主要的开发思路，也较为明晰的指出来目前在国内市场上可能的技术路径，并且均有一定的实际项目支持这些结论。虽然真正能够落地达到足够价值高度的项目还极少，但是这一块是BIM领域中难度最大的，若被攻破，则BIM无难事。
于是，这才算是真正的打通了。
本文版权归腿腿教学网及原创作者所有，未经授权，谢绝转载。
上一篇：漫谈系列24 理解的困境
下一篇：漫谈系列26 最佳实践
