談到能源數(shù)字化，很多人和我的感受是一樣的，那就是“冰火兩重天”。一邊是火熱的“能源互聯(lián)網”、“數(shù)字化能源未來”的美好暢想，各類僅存在于PPT的企業(yè)戰(zhàn)略規(guī)劃，缺錢需要及時收割韭菜的某些概念型公司。

（來源：公眾號“魚眼看電改”作者：俞慶）

另一邊是冰冷的現(xiàn)實，電力市場化并未快速到來，售電業(yè)務競爭激烈，配電業(yè)務躊躇不前，用戶對數(shù)字化能源接受度很低，政府態(tài)度積極就是不給錢。

所以今天想分享的就是對這個問題的思考，如何從現(xiàn)實走向理想。就思考的層級上看，能源互聯(lián)網首先是個技術問題，然后是個業(yè)務問題，最后是個商業(yè)問題。

今天第一篇我們先談談技術層級的問題。

從技術上看，從單一功能軟件到能源數(shù)字化平臺，還有很長的路要走。

一、單一功能軟件疊加

現(xiàn)在很多的云平臺，本質是一個或者若干功能的堆積。比如智能運維、電費優(yōu)化、能耗監(jiān)測。你把它拆開了看，本質上就是單一功能軟件。

二、（云端）軟件系統(tǒng)

從單一功能疊加到軟件系統(tǒng)，最核心的區(qū)別在于：是否實現(xiàn)了數(shù)據(jù)模型抽象化、業(yè)務流程融合化。

1、數(shù)據(jù)模型對象化，就是物理的表計數(shù)據(jù)不是被存儲為表計數(shù)據(jù)，而是變成一個“量測對象”，這個對象又能被別的對象所定義和調用。比如一個回路的測點數(shù)據(jù)，對應這個回路的量測對象，這個量測對象可以關聯(lián)到某個“線路對象”，然后支持能耗監(jiān)測，也能用來判斷故障位置，還能拿來算線損。至少我見過的很多系統(tǒng)里，表計數(shù)據(jù)就是表計數(shù)據(jù)，是需要在代碼級別去進行邏輯定義的，這種抽象層次關系的高級階段就是CIM模型，極大的擴展了靈活性，減少代碼量。

2、業(yè)務流程的融合化。舉個例子，現(xiàn)在市面上有很多“智能用電”產品，本質就是電能計量疊加一些狀態(tài)監(jiān)測數(shù)據(jù)，用來判斷線路上是否存在火災隱患。很多類似的系統(tǒng)是政策性市場銷售，但是這些系統(tǒng)一旦安裝，除了告警以外，并沒有實現(xiàn)流程閉環(huán)，缺乏對消缺的監(jiān)督，所以意義不大，屬于“煙囪型系統(tǒng)”。能否通過告警，進行故障研判和定位，確定缺陷以后，在運維管理模塊里實現(xiàn)缺陷流程的跟蹤，最終再通過信號確定消缺。這涉及到數(shù)據(jù)貫通、模型貫通和流程貫通這些問題。這才是從單一功能軟件到（云端）軟件系統(tǒng)的區(qū)別。

不要小看這三個貫通，電網公司搞了10多年信息化，現(xiàn)在還在艱難的實現(xiàn)和維持這三個貫通，比如泛在物聯(lián)搞得火熱的“營配貫通”，大把銀子就在“貫通”二字。

三、軟件云平臺

軟件云平臺，之所以被成為平臺，或者說的再時髦一點，現(xiàn)在叫做“數(shù)據(jù)中臺”和“業(yè)務中臺”，平臺化或者中臺化，本質是兩個抽象復用，即數(shù)據(jù)對象抽象化，業(yè)務功能抽象化，抽象化的本質是為了復用。

1、數(shù)據(jù)對象抽象化，即把一些通用的數(shù)據(jù)進行對象化和抽象化，實現(xiàn)三個One（阿里的數(shù)據(jù)中臺核心理論），One ID（所有對象只有唯一編碼以供索引），One Data（所有數(shù)據(jù)以統(tǒng)一的模型格式進行集中存儲），One Service（所有數(shù)據(jù)以統(tǒng)一的方式對外提供數(shù)據(jù)服務）。其實這也是電力信息化搞了這么多年走過的類似路徑，One ID和One Data的標準就是IEC CIM模型，它定義了能源數(shù)據(jù)如何被理解，然后以此為基礎通過一系列的數(shù)據(jù)架構和管理方法，才有了數(shù)據(jù)中臺。

2、業(yè)務功能抽象化。即把一些常用功能，變成可以復用的功能化組件，比如圖形引擎（接線圖、地理信息圖、甚至三維矢量圖）、組織權限管理、工作流、工單表單、建模工具、規(guī)則庫等等。還有非常重要的的一點，就是這些組件（不管是不是用第三方組件），需要被很好組合起來，調教成為一個有機的整體，對外統(tǒng)一提供調用（甚至是配置方式），而不是散亂的各自為政。這也是平臺的核心技術所在。

是否具備上述兩個方面的抽象與有機整合，并把它變成軟件平臺底層的通用部分，這才是“軟件平臺”區(qū)別于“軟件系統(tǒng)”的地方。

舉個不恰當?shù)睦樱瑔我卉浖到y(tǒng)類似于電動自行車（能跑就行），軟件系統(tǒng)類似于一個型號的小轎車（涉及到轉向、發(fā)動機、變速箱、地盤、安全氣囊等多個系統(tǒng)的整合與交互），云平臺就類似于大眾或者豐田的汽車底盤平臺，通過標準化底盤平臺，這個平臺上面可以開發(fā)多種車型，提供各種標準的軟硬件接口。

四、如何開發(fā)好的能源云平臺

1、靠譜的，懂業(yè)務的團隊。能源云平臺需要靠譜的團隊，團隊里各個專業(yè)都需要有靠譜的人才配置，最稀缺的不是程序員，而是能理解業(yè)務的程序員、懂業(yè)務的架構師，以及能理解程序的業(yè)務分析師。能源是壁壘很高、專業(yè)性很強的行業(yè)，沒有三五年的業(yè)務經驗，連一個大的專業(yè)模塊都理解不了，更不要說夸專業(yè)領域。會編程的人不少，懂能源業(yè)務的人很少。君不見某上市公司為了組建數(shù)字化團隊，從國網南網五大，以幾倍的公司挖人么。

2、深刻的理解價值和戰(zhàn)略。光有人還不夠，各路能源大企業(yè)一堆人才，目前能源云平臺還處于落地的初期，架構不可謂不宏大，功能不可謂不繁復，能產生價值的不多，能持續(xù)優(yōu)化價值的更少。因為如何在戰(zhàn)略和戰(zhàn)術層面把技術和業(yè)務價值整合，形成落地迭代的路徑，非?？简灩芾韴F隊的實戰(zhàn)能力和戰(zhàn)略視野，否則招了幾百號研發(fā)團隊，不知道戰(zhàn)略重點和研發(fā)重心，眉毛胡子一把抓，容易“寬度一公里、深度一厘米”，你都不知道往哪挖。

3、持續(xù)投入最好別燒錢。電網公司信息化歷時十余年，一個省公司每年大幾十億的數(shù)字化投入，才有了今天的智能電網。上面所說的功能融合、業(yè)務貫通、數(shù)據(jù)對象化、平臺化復用，不是憑空而來的，因為沒有人知道一開始該怎么干，曾經見過電網某個大的業(yè)務系統(tǒng)推倒重來三四次，你能說前面的錢白花了么，飯是一口口吃的。市場化的能源云平臺因為業(yè)務屬性不一樣，客戶價值不一樣，決定了電網的經驗都無法套用，更不要說缺乏能源信息化經驗的其他能源企業(yè)了。燒一筆錢容易，要在平臺上持續(xù)燒錢，據(jù)我所知已經有若干家上市公司撐不住了。

當然，燒錢不是必須的，云平臺需要真正向互聯(lián)網學習的是MVP，如何用簡單架構去滿足實用功能，先賺到錢再考慮下一次迭代是不是要推翻架構重來。當然，最理想的一種狀態(tài)就是先做好一個大架構，然后按照MVP的方式去精化功能，形成小的價值迭代，只不過這樣做對團隊以往的技術經驗要求極高，而且還不能被以前大系統(tǒng)的思維方式所束縛，我認為這才是“能源+互聯(lián)網”的玩法。

持續(xù)燒錢，考驗的不僅僅是團隊本身，更重要的是考驗整個公司最高決策者的戰(zhàn)略眼光、戰(zhàn)略定力和協(xié)調推進能力，這絕對不是數(shù)字化團隊本身所能解決的問題。能源行業(yè)過去市場化程度很低，導致部分決策層對市場化業(yè)務的趨勢、速度和路徑理解不足，我認為這才是一家公司在開發(fā)和推進云平臺中最大的戰(zhàn)略風險，說白點就是老板看不懂，一開始被忽悠上船，現(xiàn)在覺得燒錢有點后悔，要么收手不敢（舍不得），要么繼續(xù)燒錢（還是舍不得），這種兩難境地的團隊也有不少。所以這是涉及到業(yè)務模式和商業(yè)模式的問題，我們后文再談。

無論在不在大公司，只要在云平臺團隊，你就是創(chuàng)業(yè)，創(chuàng)業(yè)維艱，且行且珍惜。