从软件到能源数字化平台,有多远的路要走?
发布者:lzx | 来源:鱼眼看电改 | 0评论 | 3158查看 | 2020-05-07 09:42:42    

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


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


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


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


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


一、单一功能软件叠加


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


二、(云端)软件系统


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


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


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


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


三、软件云平台


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


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


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


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


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


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


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


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


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


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


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


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

最新评论
0人参与
马上参与
最新资讯