从软件到能源数字化商业模式路有多远？

谈到能源数字化，很多人和我的感受是一样的，那就是“冰火两重天”。一边是火热的“能源互联网”、“数字化能源未来”的美好畅想，各类仅存在于PPT的企业战略规划，缺钱需要及时收割韭菜的某些概念型公司。

（来源：微信公众号”鱼眼看电改“ 作者：俞庆）

另一边是冰冷的现实，电力市场化并未快速到来，售电业务竞争激烈，配电业务踌躇不前，用户对数字化能源接受度很低，政府态度积极就是不给钱。

所以今天想分享的就是对这个问题的思考，如何从现实走向理想。就思考的层级上看，能源互联网首先是个技术问题，然后是个业务问题，最后是个商业问题。

今天第一篇我们先谈谈技术层级的问题。

从技术上看，从单一功能软件到能源数字化平台，还有很长的路要走。

一、单一功能软件叠加

现在很多的云平台，本质是一个或者若干功能的堆积。比如智能运维、电费优化、能耗监测。你把它拆看了看，本质上就是单一功能软件。

二、（云端）软件系统

从单一功能叠加到软件系统，最核心的区别在于：是否实现了数据模型抽象化、业务流程融合化。

1、数据模型对象化，就是物理的表计数据不是被存储为表计数据，而是变成一个“量测对象”，这个对象又能被别的对象所定义和调用。比如一个回路的测点数据，对应这个回路的量测对象，这个量测对象可以关联到某个“线路对象”，然后支持能耗监测，也能用来判断故障位置，还能拿来算线损。至少我见过的很多系统里，表计数据就是表计数据，是需要在代码级别去进行逻辑定义的，这种抽象层次关系的高级阶段就是CIM模型，极大的扩展了灵活性，减少代码量。

2、业务流程的融合化。举个例子，现在市面上有很多“智能用电”产品，本质就是电能计量叠加一些状态监测数据，用来判断线路上是否存在火灾隐患。很多类似的系统是政策性市场销售，但是这些系统一旦安装，除了告警以外，并没有实现流程闭环，缺乏对消缺的监督，所以意义不大，属于“烟囱型系统”。能否通过告警，进行故障研判和定位，确定缺陷以后，在运维管理模块里实现缺陷流程的跟踪，最终再通过信号确定消缺。这涉及到数据贯通、模型贯通和流程贯通这些问题。这才是从单一功能软件到（云端）软件系统的区别。

不要小看这三个贯通，电网公司搞了10多年信息化，现在还在艰难的实现和维持这三个贯通，比如泛在物联搞得火热的“营配贯通”，大把银子就在“贯通”二字。

三、软件云平台

软件云平台，之所以被成为平台，或者说的再时髦一点，现在叫做“数据中台”和“业务中台”，平台化或者中台化，本质是两个抽象复用，即数据对象抽象化，业务功能抽象化，抽象化的本质是为了复用。

1、数据对象抽象化，即把一些通用的数据进行对象化和抽象化，实现三个One（阿里的数据中台核心理论），One ID（所有对象只有唯一编码以供索引），One Data（所有数据以统一的模型格式进行集中存储），One Service（所有数据以统一的方式对外提供数据服务）。其实这也是电力信息化搞了这么多年走过的类似路径，One ID和One Data的标准就是IEC CIM模型，它定义了能源数据如何被理解，然后以此为基础通过一系列的数据架构和管理方法，才有了数据中台。

2、业务功能抽象化。即把一些常用功能，变成可以复用的功能化组件，比如图形引擎（接线图、地理信息图、甚至三维矢量图）、组织权限管理、工作流、工单表单、建模工具、规则库等等。还有非常重要的的一点，就是这些组件（不管是不是用第三方组件），需要被很好组合起来，调教成为一个有机的整体，对外统一提供调用（甚至是配置方式），而不是散乱的各自为政。这也是平台的核心技术所在。

是否具备上述两个方面的抽象与有机整合，并把它变成软件平台底层的通用部分，这才是“软件平台”区别于“软件系统”的地方。

举个不恰当的例子，单一软件系统类似于电动自行车（能跑就行），软件系统类似于一个型号的小轿车（涉及到转向、发动机、变速箱、地盘、安全气囊等多个系统的整合与交互），云平台就类似于大众或者丰田的汽车底盘平台，通过标准化底盘平台，这个平台上面可以开发多种车型，提供各种标准的软硬件接口。

四、如何开发好的能源云平台

1、靠谱的，懂业务的团队。能源云平台需要靠谱的团队，团队里各个专业都需要有靠谱的人才配置，最稀缺的不是程序员，而是能理解业务的程序员、懂业务的架构师，以及能理解程序的业务分析师。能源是壁垒很高、专业性很强的行业，没有三五年的业务经验，连一个大的专业模块都理解不了，更不要说夸专业领域。会编程的人不少，懂能源业务的人很少。君不见某上市公司为了组建数字化团队，从国网南网五大，以几倍的公司挖人么。

2、深刻的理解价值和战略。光有人还不够，各路能源大企业一堆人才，目前能源云平台还处于落地的初期，架构不可谓不宏大，功能不可谓不繁复，能产生价值的不多，能持续优化价值的更少。因为如何在战略和战术层面把技术和业务价值整合，形成落地迭代的路径，非常考验管理团队的实战能力和战略视野，否则招了几百号研发团队，不知道战略重点和研发重心，眉毛胡子一把抓，容易“宽度一公里、深度一厘米”，你都不知道往哪挖。

3、持续投入最好别烧钱。电网公司信息化历时十余年，一个省公司每年大几十亿的数字化投入，才有了今天的智能电网。上面所说的功能融合、业务贯通、数据对象化、平台化复用，不是凭空而来的，因为没有人知道一开始该怎么干，曾经见过电网某个大的业务系统推倒重来三四次，你能说前面的钱白花了么，饭是一口口吃的。市场化的能源云平台因为业务属性不一样，客户价值不一样，决定了电网的经验都无法套用，更不要说缺乏电网信息化经验的其他能源企业了。烧一笔钱容易，要在平台上持续烧钱，据我所知已经有若干家上市公司撑不住了。

当然，烧钱不是必须的，云平台需要真正向互联网学习的是MVP，如何用简单架构去满足实用功能，先赚到钱再考虑下一次迭代是不是要推翻架构重来。当然，最理想的一种状态就是先做好一个大架构，然后按照MVP的方式去精化功能，形成小的价值迭代，只不过这样做对团队以往的技术经验要求极高，而且还不能被以前大系统的思维方式所束缚，我认为这才是“能源+互联网”的玩法。

持续烧钱，考验的不仅仅是团队本身，更重要的是考验整个公司最高决策者的战略眼光、战略定力和协调推进能力，这绝对不是数字化团队本身所能解决的问题。能源行业过去市场化程度很低，导致部分决策层对市场化业务的趋势、速度和路径理解不足，我认为这才是一家公司在开发和推进云平台中最大的战略风险，说白点就是老板看不懂，一开始被忽悠上船，现在觉得烧钱有点后悔，要么收手不敢（舍不得），要么继续烧钱（还是舍不得），这种两难境地的团队也有不少。所以这是涉及到业务模式和商业模式的问题，我们后文再谈。

无论在不在大公司，只要在云平台团队，你就是创业，创业维艰，且行且珍惜。