微信客服
微信公眾號
談到能源數字化，很多人和我的感受是一樣的，那就是“冰火兩重天”。一邊是火熱的“能源互聯網”、“數字化能源未來”的美好暢想，各類僅存在于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的方式去精化功能，形成小的價值迭代，只不過這樣做對團隊以往的技術經驗要求極高，而且還不能被以前大系統的思維方式所束縛，我認為這才是“能源+互聯網”的玩法。
持續燒錢，考驗的不僅僅是團隊本身，更重要的是考驗整個公司最高決策者的戰略眼光、戰略定力和協調推進能力，這絕對不是數字化團隊本身所能解決的問題。能源行業過去市場化程度很低，導致部分決策層對市場化業務的趨勢、速度和路徑理解不足，我認為這才是一家公司在開發和推進云平臺中最大的戰略風險，說白點就是老板看不懂，一開始被忽悠上船，現在覺得燒錢有點后悔，要么收手不敢（舍不得），要么繼續燒錢（還是舍不得），這種兩難境地的團隊也有不少。所以這是涉及到業務模式和商業模式的問題，我們后文再談。
無論在不在大公司，只要在云平臺團隊，你就是創業，創業維艱，且行且珍惜。
（來源：公眾號“魚眼看電改”作者：俞慶）
另一邊是冰冷的現實，電力市場化并未快速到來，售電業務競爭激烈，配電業務躊躇不前，用戶對數字化能源接受度很低，政府態度積極就是不給錢。
所以今天想分享的就是對這個問題的思考，如何從現實走向理想。就思考的層級上看，能源互聯網首先是個技術問題，然后是個業務問題，最后是個商業問題。
今天第一篇我們先談談技術層級的問題。
從技術上看，從單一功能軟件到能源數字化平臺，還有很長的路要走。
一、單一功能軟件疊加
現在很多的云平臺，本質是一個或者若干功能的堆積。比如智能運維、電費優化、能耗監測。你把它拆開了看，本質上就是單一功能軟件。
二、（云端）軟件系統
從單一功能疊加到軟件系統，最核心的區別在于：是否實現了數據模型抽象化、業務流程融合化。
1、數據模型對象化，就是物理的表計數據不是被存儲為表計數據，而是變成一個“量測對象”，這個對象又能被別的對象所定義和調用。比如一個回路的測點數據，對應這個回路的量測對象，這個量測對象可以關聯到某個“線路對象”，然后支持能耗監測，也能用來判斷故障位置，還能拿來算線損。至少我見過的很多系統里，表計數據就是表計數據，是需要在代碼級別去進行邏輯定義的，這種抽象層次關系的高級階段就是CIM模型，極大的擴展了靈活性，減少代碼量。
2、業務流程的融合化。舉個例子，現在市面上有很多“智能用電”產品，本質就是電能計量疊加一些狀態監測數據，用來判斷線路上是否存在火災隱患。很多類似的系統是政策性市場銷售，但是這些系統一旦安裝，除了告警以外，并沒有實現流程閉環，缺乏對消缺的監督，所以意義不大，屬于“煙囪型系統”。能否通過告警，進行故障研判和定位，確定缺陷以后，在運維管理模塊里實現缺陷流程的跟蹤，最終再通過信號確定消缺。這涉及到數據貫通、模型貫通和流程貫通這些問題。這才是從單一功能軟件到（云端）軟件系統的區別。
不要小看這三個貫通，電網公司搞了10多年信息化，現在還在艱難的實現和維持這三個貫通，比如泛在物聯搞得火熱的“營配貫通”，大把銀子就在“貫通”二字。
三、軟件云平臺
軟件云平臺，之所以被成為平臺，或者說的再時髦一點，現在叫做“數據中臺”和“業務中臺”，平臺化或者中臺化，本質是兩個抽象復用，即數據對象抽象化，業務功能抽象化，抽象化的本質是為了復用。
1、數據對象抽象化，即把一些通用的數據進行對象化和抽象化，實現三個One（阿里的數據中臺核心理論），One ID（所有對象只有唯一編碼以供索引），One Data（所有數據以統一的模型格式進行集中存儲），One Service（所有數據以統一的方式對外提供數據服務）。其實這也是電力信息化搞了這么多年走過的類似路徑，One ID和One Data的標準就是IEC CIM模型，它定義了能源數據如何被理解，然后以此為基礎通過一系列的數據架構和管理方法，才有了數據中臺。
2、業務功能抽象化。即把一些常用功能，變成可以復用的功能化組件，比如圖形引擎（接線圖、地理信息圖、甚至三維矢量圖）、組織權限管理、工作流、工單表單、建模工具、規則庫等等。還有非常重要的的一點，就是這些組件（不管是不是用第三方組件），需要被很好組合起來，調教成為一個有機的整體，對外統一提供調用（甚至是配置方式），而不是散亂的各自為政。這也是平臺的核心技術所在。
是否具備上述兩個方面的抽象與有機整合，并把它變成軟件平臺底層的通用部分，這才是“軟件平臺”區別于“軟件系統”的地方。
舉個不恰當的例子，單一軟件系統類似于電動自行車（能跑就行），軟件系統類似于一個型號的小轎車（涉及到轉向、發動機、變速箱、地盤、安全氣囊等多個系統的整合與交互），云平臺就類似于大眾或者豐田的汽車底盤平臺，通過標準化底盤平臺，這個平臺上面可以開發多種車型，提供各種標準的軟硬件接口。
四、如何開發好的能源云平臺
1、靠譜的，懂業務的團隊。能源云平臺需要靠譜的團隊，團隊里各個專業都需要有靠譜的人才配置，最稀缺的不是程序員，而是能理解業務的程序員、懂業務的架構師，以及能理解程序的業務分析師。能源是壁壘很高、專業性很強的行業，沒有三五年的業務經驗，連一個大的專業模塊都理解不了，更不要說夸專業領域。會編程的人不少，懂能源業務的人很少。君不見某上市公司為了組建數字化團隊，從國網南網五大，以幾倍的公司挖人么。
2、深刻的理解價值和戰略。光有人還不夠，各路能源大企業一堆人才，目前能源云平臺還處于落地的初期，架構不可謂不宏大，功能不可謂不繁復，能產生價值的不多，能持續優化價值的更少。因為如何在戰略和戰術層面把技術和業務價值整合，形成落地迭代的路徑，非常考驗管理團隊的實戰能力和戰略視野，否則招了幾百號研發團隊，不知道戰略重點和研發重心，眉毛胡子一把抓，容易“寬度一公里、深度一厘米”，你都不知道往哪挖。
3、持續投入最好別燒錢。電網公司信息化歷時十余年，一個省公司每年大幾十億的數字化投入，才有了今天的智能電網。上面所說的功能融合、業務貫通、數據對象化、平臺化復用，不是憑空而來的，因為沒有人知道一開始該怎么干，曾經見過電網某個大的業務系統推倒重來三四次，你能說前面的錢白花了么，飯是一口口吃的。市場化的能源云平臺因為業務屬性不一樣，客戶價值不一樣，決定了電網的經驗都無法套用，更不要說缺乏能源信息化經驗的其他能源企業了。燒一筆錢容易，要在平臺上持續燒錢，據我所知已經有若干家上市公司撐不住了。
當然，燒錢不是必須的，云平臺需要真正向互聯網學習的是MVP，如何用簡單架構去滿足實用功能，先賺到錢再考慮下一次迭代是不是要推翻架構重來。當然，最理想的一種狀態就是先做好一個大架構，然后按照MVP的方式去精化功能，形成小的價值迭代，只不過這樣做對團隊以往的技術經驗要求極高，而且還不能被以前大系統的思維方式所束縛，我認為這才是“能源+互聯網”的玩法。
持續燒錢，考驗的不僅僅是團隊本身，更重要的是考驗整個公司最高決策者的戰略眼光、戰略定力和協調推進能力，這絕對不是數字化團隊本身所能解決的問題。能源行業過去市場化程度很低，導致部分決策層對市場化業務的趨勢、速度和路徑理解不足，我認為這才是一家公司在開發和推進云平臺中最大的戰略風險，說白點就是老板看不懂，一開始被忽悠上船，現在覺得燒錢有點后悔，要么收手不敢（舍不得），要么繼續燒錢（還是舍不得），這種兩難境地的團隊也有不少。所以這是涉及到業務模式和商業模式的問題，我們后文再談。
無論在不在大公司，只要在云平臺團隊，你就是創業，創業維艱，且行且珍惜。
0 條